Laden...

Was muss ich bei einem Server mit ASP-Schnittstelle beachten?

Erstellt von Frokuss vor 4 Jahren Letzter Beitrag vor 4 Jahren 2.780 Views
F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren
Was muss ich bei einem Server mit ASP-Schnittstelle beachten?

Hallo Leute,

ich habe bisher noch kaum Erfahrung mit "Netzwerk"... Ich möchte allerdings eine Server-Client-Anwendung erstellen, bei der es auch eine Browser-Schnittstelle gibt.
Dafür brauche ich glaube ich allerdings ASP(X)? Kann mir jemand sagen, was ich berücksichtigen muss, wenn ich möchte dass jemand aus dem Browser mit einem aus dem Client kommunizieren kann?
Habe auch noch nie etwas mit ASP gemacht 😄
Bin eigentlich für Literatur Tipps dankbar...

Gruß Frokuss

M
368 Beiträge seit 2006
vor 4 Jahren

Also so etwas wie ein Chat-Programm ? Da könnte dieser Artikel inspirieren: https://www.codeproject.com/Articles/732190/Real-Time-Web-Solution-for-Chat-by-MVC-SignalR-H

Ansonsten ist ASP die uralte Technologie und ASP.NET (Core) das neuere.

Goalkicker.com // DNC Magazine for .NET Developers // .NET Blogs zum Folgen
Software is like cathedrals: first we build them, then we pray 😉

16.806 Beiträge seit 2008
vor 4 Jahren

Einfach mal in die Microsoft Docs schauen.
Die sind gut, aktiv und aktuell - dafür sind sie da.

wenn ich möchte dass jemand aus dem Browser mit einem aus dem Client kommunizieren kann?

Die Frage kann man missverstehen; und ASP.NET wird hier alleine keine Lösung sein, sofern Du mit Client ein Desktop Programm meinst.
Da wirst Du schnell in Infrastruktur-Architektur kommen bzgl. Firewall und Co.

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

@M.I.: genau, quasi nen Chat. Danke dir 😃
@Abt: Ja, mit Client meinte ich Desktop, später vielleicht auch mal fürs Mobile-Endgerät. Sorry keiner vom Fach..

Einfach mal in die Microsoft Docs schauen.
Die sind gut, aktiv und aktuell - dafür sind sie da.

Durfte mir aber bereits häufiger anhören, dass ich auf veralteter Technik was mache... Und wollte es dann einfach mal anders angehen XD

Den Artikel habe ich ersteinmal überflogen und scheint in die RIchtung zu gehen, die ich dachte. Danke <3

Vielen Dnake euch beiden
Frokuss

16.806 Beiträge seit 2008
vor 4 Jahren

Ja, mit Client meinte ich Desktop, später vielleicht auch mal fürs Mobile-Endgerät.

Dann fang lieber mal mit der Infrastruktur-Architektur an, bevor Du Dich an die Implementierung machst...

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

Ja... zum Server werde ich auch noch einige Fragen haben ^^ Hatt vor ca. 1,5 Jahren mal was gemacht, bei dem jede Verbindung in einen eigenen Thread war... Denke da nun in Richtung Prozess... Aber das muss ich mal gucken... kenne ich mich noch nicht mit aus und werde mich wohl bei Zeiten an euch wenden.

Bevor ich aber mit der Infrastruktur anfange, muss ich erst einmal gucken, wie das geht... Hatte schon genug Probleme ersteinmal mich hier zurecht zu finden, wo welche files liegen...

Gruß Frokuss

16.806 Beiträge seit 2008
vor 4 Jahren

bei dem jede Verbindung in einen eigenen Thread war... Denke da nun in Richtung Prozess...

Pro Verbindung ein Prozess? Das hört sich nicht nach einem guten Plan an 🙂
Schau Dir in Ruhe die Basics bei HTTP und Co an, dann wirst das sehr schnell merken =)

Bevor ich aber mit der Infrastruktur anfange, muss ich erst einmal gucken, wie das geht...

Prinzipiell sollte man bei so einem Vorhaben mit der Infrastruktur anfangen: Du solltest erst mal schauen, wie Du überhaupt mit allen Teilnehmern aus Netzwerksicht eine Verbindung aufbauen kannst.
Stichwort: Firewall.

Du wirst nämlich von "Außen" nicht so einfach eine Verbindung auf einen PC und dessen Anwendung bekommen - und das ist auch gut so 😉

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

Ehm... Momentmal... worüber genau sprechen wir grade? Über "Webseite" zum Server, oder über (Desktop)-App zum Server? Oder laufen beide über HTTP? O.o

Ich habe mal vor 1,5 Jahre das mit ner Stream-Variante gemacht (glaube Networkstream) und konnte zumindestens innerhalb des Netzwerkes mit einem anderen Gerät eine Verbindung aufbauen und Nachrichten austauschen...

Also mein Grundgedanke war, dass ich jedem User einen Thread (Prozess hast du ja abgeraten) zuweise und dort sämtliche Verbindungen von ihm habe. Damit könnte er mit mehreren Geräten eingelogt sein. Das ganze dann über einen Dictionary geregelt, so dass ich anhand der User-ID auf den entsprechenden Thread zugreifen kann und dort dann die Nachricht senden kann. Das hat zumindestens im super kleinen (4 Geräte) geklappt XD

Gruß Frokuss

16.806 Beiträge seit 2008
vor 4 Jahren

Ehm... Momentmal... worüber genau sprechen wir grade?

Ich spreche gerade von jeglicher Art der Kommunikation von "Außen" auf eine Anwendung, wie Du es beschrieben hast.

und konnte zumindestens innerhalb des Netzwerkes mit einem anderen Gerät eine Verbindung aufbauen und Nachrichten austauschen...

Dann war da mit Sicherheit keine Firewall im Spiel.

Also mein Grundgedanke war, dass ich jedem User einen Thread (Prozess hast du ja abgeraten) zuweise und dort sämtliche Verbindungen von ihm habe.

Was ist "dort" und was ist "sämtliche" ?
Es kommt ganz drauf an was Du vor hast.

Damit könnte er mit mehreren Geräten eingelogt sein. Das ganze dann über einen Dictionary geregelt, so dass ich anhand der User-ID auf den entsprechenden Thread zugreifen kann und dort dann die Nachricht senden kann.

Du gehst viel viel viel zu konkret vor.
Mach Dir über Prozesse und Threads mal überhaupt keine Sorgen sondern überleg Dir erst mal wer wie und über was eine Verbindung erstellen soll.
Das ist der entscheidende Punkt in Deinem gesamten Konzept und entscheidet am Ende vom Tag auch die Technologien.

Du brauchst Duch auch mit Low Level Connectivity wie NetworkStreams eigentlich in Zeiten von WebSockets und gRPC gar nicht kümmern.
Aber dass Du überhaupt eine Verbindung aufbauen kannst, zB. wegen Netzwerkregeln, Security und Co: darüber solltest Du Dir erstmal Gedanken machen.

Dir bringt der Einsatz einer Technologie gar nichts, wenn Du Dich für einen Weg entschieden hast, der konzeptionell in echten Umgebungen gar nicht funktionieren kann.

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

Also mein Grundgedanke war, dass ich jedem User einen Thread (Prozess hast du ja abgeraten) zuweise und dort sämtliche Verbindungen von ihm habe.

Was ist "dort" und was ist "sämtliche" ?
Es kommt ganz drauf an was Du vor hast.

Damit meinte ich, dass ich in einem Thread alle Verbindungen eines einzelnen Anwenders habe. Daher, es kann ein Anwender über mehrere gleichzeitig Geräte verbunden sein. Bekommt er also z.B. eine private Nachricht, wird diese an all seine Endgeräte geschickt. Eigentlich auch alle anderen Nachrichten XD Das ist zumindestens das Ziel.

Dir bringt der Einsatz einer Technologie gar nichts, wenn Du Dich für einen Weg entschieden hast, der konzeptionell in echten Umgebungen gar nicht funktionieren kann.

Da stimme ich dir vollkommen zu. Ich dachte allerdings, dass ich einfach eine Verbindung aufbaue, dann kommt eh ne Firewall -Meldung - unter Windows - für ne Ausnahme am Client-System und das ganze ist geregelt?

Wo ich vermutlich Probleme haben werde ist, wie ich es schaffe, dass jemand aus dem Browser mit einem aus meiner Desktop-App kommuniziert. Das ganze wird ja eh über den Server laufen - so viel steht ja eh fest; zumindestens für mich.
Wenn ich die Quelle von M.I. richtig verstanden habe, geht es dort um "Browser zu Browser". Hilft mir aber dahingehend, das ich zumindestens erst einmal herausfinden kann, was wie wo mit diesem Ansatz geht. Bin da allerdings noch dran.

Gruß Frokuss

16.806 Beiträge seit 2008
vor 4 Jahren

Damit meinte ich, dass ich in einem Thread alle Verbindungen eines einzelnen Anwenders habe. Daher, es kann ein Anwender über mehrere gleichzeitig Geräte verbunden sein.

Verwende mal bitte nicht das Wort Thread oder Process, das ist hier egal.

Wo ich vermutlich Probleme haben werde ist, wie ich es schaffe, dass jemand aus dem Browser mit einem aus meiner Desktop-App kommuniziert.

Du brauchst in so einem Fall immer einen zentralen Punkt, mit denen sich alle Sender und alle Empfänger verbinden (typisch Client-Server).
Nur dann verhinderst Du konzeptionelle Probleme in Sachen Firewall und Co.

Bekommt er also z.B. eine private Nachricht, wird diese an all seine Endgeräte geschickt.

Genau das ist es: Du kannst Dich von Außen nicht auf ein Gerät aufschalten.
Das verhindert jedes Sicherheitskonzept und jede Anwendung.

Daher meine Nachfragen: weil so formuliert funktioniert Dein Vorhaben auf keinen Fall.
Weder Desktop noch Mobil.

Du kannst aktiv keine Verbindung zum Empfänger aufbauen.
Der Empfänger muss die Verbindung öffnen und dann zuhören. So funktioniert zB auch SignalR (oder andere Message-basierte Kommunikationskanäle wie MQTT/AMQP....).

Da stimme ich dir vollkommen zu. Ich dachte allerdings, dass ich einfach eine Verbindung aufbaue, dann kommt eh ne Firewall -Meldung - unter Windows - für ne Ausnahme am Client-System und das ganze ist geregelt?

Nein, die Meldung kommt nicht, wenn Du von Außen versuchst eine Verbindung aufzubauen.
Standardmäßig würde jede Firewall den Verbindungsaufbau blockieren. Das ist ihre Aufgabe.

Der Link von M.I. zeigt eben eine Client-Server Architektur. "Browser to Browser" wäre in der Formulierung Peer-to-Peer und eben das andere, direkte Konzept.

Wenn Du Cloud Technologien verwenden kannst, dann nimmt Dir der Azure SignalR Service 80% der Infrastruktur ab.
In der Übersichtsseite siehst Du auch schon Best Practise Architekturen, an denen Du Dich orientieren kannst (auch ohne Azure).
https://azure.microsoft.com/de-de/services/signalr-service/

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

Also... ich glaube ich drücke mich ein wenig sehr umständlich aus... Sorry dafür!

Für mich steht fest, dass das ganze nur klappen kann, wenn es eine Stelle gibt, die alle kennt. Das ist meiner Auffassung nach die Aufgabe vom Server. Dieser leitet dann alles an die entsprechenden Clients weiter.
Dem Server sind die Clients erst bekannt, wenn diese sich bei ihm melden/registrieren.

Wenn du das mit der Architektur meinst, dann sind wir uns einige.

Ich habe aber bis dato noch nie mit ASP.NET und so irgendetwas gemacht. Und genau dies ist mein großes Fragezeichen. Bedeutet, im Idealfall kann ich das ganze in genau einer Serveranwendung implementieren. Ansonsten muss ich gucken, wie diese beiden Server-Teile kommunizieren können.

Das ganze HTML/CSS/JS-Zeugs stellt im Grunde kein Problem dar (auch wenn ich mit jQuerry noch nie etwas gemacht habe).

Werde mir mal das Azure angucken. Danke 😃

Frokuss

EDIT: Achso ne, das scheidet aus. Wills ja selber machen/lernen ^^ Und wenn ich dafür 2 Jahre brauche ist es auch okay 😃
Ist nur nen Hobbie von mir. Also nichts mit beruflichen Kontext.

16.806 Beiträge seit 2008
vor 4 Jahren

Ja, Du kannst ASP.NET Core mit SignalR als zentralen Punkt nehmen, mit denen sich dann alle Clients verteilen.
Aber auch gRPC wäre ein Weg.

F
Frokuss Themenstarter:in
158 Beiträge seit 2015
vor 4 Jahren

Cool danke 😃 Dann gucke ich mir das alles mal näher an 😃