Du bist nicht angemeldet.

Werbeanzeige

Nox

Supermoderator

Beiträge: 5 265

Beruf: Student

  • Private Nachricht senden

11

27.01.2019, 21:49

Also geht es um eine Webanwendung? Weil soweit ich weiß ist nur in dem Fall Websocket wirklich sinnvoll. Für "native" Anwendungen ist die Verwendung von HTTP(S) um eine Dauerverbindung auszuhandeln nach meinem Kenntnisstand nur ein Umweg.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

BlueCobold

Community-Fossil

Beiträge: 10 880

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

12

27.01.2019, 22:12

Und dazu noch ein ziemlich langsamer.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Goldwing Studios

Treue Seele

Beiträge: 332

Wohnort: Heidelberg

Beruf: Softwareentwickler, Vertriebler

  • Private Nachricht senden

13

28.01.2019, 09:31

Was wäre denn eine bessere/schnellere Alternative?
(das Hilft dem TE bestimmt auch)

birdfreeyahoo

Alter Hase

  • »birdfreeyahoo« ist der Autor dieses Themas

Beiträge: 764

Wohnort: Schorndorf

Beruf: Junior Software Engineer

  • Private Nachricht senden

14

28.01.2019, 16:24

Was mir wichtig ist:
- beidseitige Kommunikation zu beliebigem Zeitpunkt
- TCP-basiert mit SSL-Verschlüsselungsoption
- Verfügbarkeit für C# und Java

Bei Websocket fand ich die Schnittstelle toll mit den Callbacks (das ist eigentlich das was ich will), sowie der automatische Heartbeat-Mechanismus.

Nox

Supermoderator

Beiträge: 5 265

Beruf: Student

  • Private Nachricht senden

15

28.01.2019, 20:08

Ich kenne mich wie gesagt mit Java nicht aus und mit C# nur rudimentär, aber zumindest für C# (bzw genauer .NET) scheint es mit TcpClient/TcpListener und SslStream eine recht einfache Variante zu geben (so behauptet es zumindest Google). Ein kurzer Blick in die Doku scheint auch den Verdacht zu bestätigen, dass man damit auch asynchron bzw select artig arbeiten kann.
Für java müsste ich eben nochmal google anschmeißen bzw auf java .net verweisen, aber ich glaube das kann auch jeder für sich selbst machen.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Goldwing Studios

Treue Seele

Beiträge: 332

Wohnort: Heidelberg

Beruf: Softwareentwickler, Vertriebler

  • Private Nachricht senden

16

29.01.2019, 09:56

Was ist aber, wenn ich die Software nun auch ins Web heben will?

Also Connections per Javascript erwarte? Dann habe ich das mit SignalR/Websocket direkt drin und muss nicht erst noch umplanen.

Gut, das ist sehr Anwendungsspezifisch, aber eben doch ein sehr starker Vorteil.

Noch dazu müsstest du einen Port bestimmen/freigeben über den die Anwendung läuft, um darauf horchen zu können. Bei Websocket ist es der normale HTTP(S)-Port.
Kein extra Risiko.

Ich möchte hier aber keine Grundsatzdiskussion zwischen den beiden Architekturen anfangen, beide haben Vor- und Nachteile je nach Anwendung.

Nox

Supermoderator

Beiträge: 5 265

Beruf: Student

  • Private Nachricht senden

17

29.01.2019, 13:15

Darum fragte ich ob es sich um eine Webanwendung handelt. In den genannten Specs steht auch nichts von wegen Webanwendung. Natürlich kann es vorteilhaft sein, diese Funktionalität anbieten zu können. Aber man muss sich auch der Frage stellen, ob man es braucht. Denn feature creep kann ganz schnell unangenehm werden. Auch kommen features oft nicht umsonst (overhead).

Das mit der Portfreigabe ist übrigens ein amüsantes Argument. Immerhin muss der Port 80 bzw 8080 ja auch freigegeben werden. Was nun eine Freigabe auf einem anderen Port mit (zusätzlichem) Risiko zu tun hat weiß ich nicht. Prinzipiell kann man an jeden (frei verfügbaren) Port auch beliebiges hängen. Das auf 80/8080 ein Webserver antwortet ist ja nur Konvention und kein muss soweit ich weiß.

TL;DR

Websocket gut für Webanwendung. Websocket nicht automatisch beste Lösung für andere Anwendungen.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Schorsch

Supermoderator

Beiträge: 5 162

Wohnort: Wickede

Beruf: Student

  • Private Nachricht senden

18

29.01.2019, 13:21

Prinzipiell kann man an jeden (frei verfügbaren) Port auch beliebiges hängen. Das auf 80/8080 ein Webserver antwortet ist ja nur Konvention und kein muss soweit ich weiß.

Das ist richtig. Was du über welchen Port anstellst ist egal. Du kannst deinen Webserver auch auf Port 1337 laufen lassen wenn du möchtest, und genau so gut kannst du auf Port 80 beliebige andere Anwendungen, bzw Protokolle laufen lassen.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

birdfreeyahoo

Alter Hase

  • »birdfreeyahoo« ist der Autor dieses Themas

Beiträge: 764

Wohnort: Schorndorf

Beruf: Junior Software Engineer

  • Private Nachricht senden

19

29.01.2019, 15:22

Also es ist eher unrealistisch dass das eine Webanwendung wird. Port ist auch gar kein Problem. Die nativen TCP-Schnittstellen der jeweiligen Standardbibliotheken sind bisher auch in Verwendung. Ich überarbeite den Teil nur und hatte auch ein Auge auf Websocket geworfen. Bei der eigenen Implementierung muss man eben noch auf mehr achten bzw. mehr selber machen.

Werbeanzeige