Websockets (how to)

B

ByteSurfer

0
Guten Morgen,
ein paar Fragen meinerseits ... :)

Ich möchte unsere Applikation "etwas" entlasten, und unser polling (via Ajax) abschalten und auf websockets switchen.

Ehrlich gesagt kenne ich die Socket-Programmierung aus meiner Zeit via Java/ Remote usw., und sollte vom Verständnis (UDP/TCPIP, Ports, ACK, Handshakes ... usw. ) nicht so das Problem sein.

Noch dazu hat ByteSurfer sich ein Buch gekauft, um hier die Basics 2014
aufzufrischen ... ;)

Meine Schwierigkeit hier ist es das ganze auf einem Webserver in die Gänge zu bekommen. Sprich, wie muss ich den Webserver (Apache) konfigurieren, bzw. was für Module, wenn von nöten, benötige ich um eine Kommunikation zu erstellen.

Client-seitig dachte ich an node.js, jedoch haben einige im Netz davon abgeraten aus Gründen der Trägheit ... ???
Deswegen werde ich wohl weiterhin bei Dojo und dem damit verbundenen Framework bleiben ...

Hat jemand Erfahrungen, oder Empfehlungen, bevor ich mich aus unwissenheit für das falsche entscheide ? Und wie bereits gefragt, wie läuft das mit dem Apache ???


greetz
 
Zuletzt bearbeitet:
Hallo!
Das du Applikationen schreibst die dem ersten Anscheinen nach produktiv eingesetzt werden finde ich erschreckend.

NodeJs ist ein Javascript Server, hat nichts mit Client zu tun.
Websockets sind eigentlich für Peer-2-Peer verbindungen super gut.
Gibt gute Bibliotheken dazu, solltest du aus welchem Grund auch immer nicht darauf zurückgreifen wollen, stelle ich dir gerne Code zur verfügung.
Für Client-Server Verbindungen gibt es SocketIO.
Diese Bibliothek nimmt dir viele Details der Websocketprogrammierung ab.
Ist aber nur minimal dokumentiert, man hat öfters das Gefühl das bestimmte Dokumentationen fehlen.
Ist aber auch kein Wunder, wenn man sich die Commits anschaut, 1 Haupt-Entwickler ist halt schon echt hart für so ein komplexes Projekt.

Apache kann IMO keine Websockets.
Für Peer-2-Peer-Verbindungen brauchst du auch keine, denn der Signaling-Channel kann eine xbeliebige/s Protokoll/Technologie haben.
Es ist also wichtig wofür du die Websockets einsetzten möchtest.

Der Techstack ist auch wichtig.
PHP hat z.B. einen Websocketserver, aber den kann man nicht auf Apache laufen lassen, da der Server nicht wiederkommt, und forken ist im Apachekontext böse, ganz abgesehen von der max. Skriptlaufzeit.(Konsolenkontext wäre eine alternative, aber da müsste man recht viel Konfigurieren, was passiert z.B. wenn Ratchet mal abstürzt, wie willst du sicherstellen das Rachtecht automatisch wiederkehrt?)
Apache sieht URL's und Dateien, NGinx ist im Herzen eher ein Proxy.
NGinx zusammen mit nodeJS ist eigentlich eine bewährte Kombination.

Alternativ kann man auch nodeJS direkt ins Netz hängen, aber dann müsste man diesen gut absichern.

Aber dafür müsste man mehr erfahren(Techstack, Einsatzszenario, etc)
Gruß

Fluffy

P.s.:Ich glaube nicht das nodeJS Trägheitsprobleme hat.
Der Server ist eigentlich superfix, wenn man ihn richtig einsetzt.
Da haben wohl einige viele Dateien mittels NodeJS verteilen lassen:rolleyes:


Edit:
JS-Bibliotheken für Peer-2-Peer:
ChatJS, PeerJS

Edit2:
Hab deinen Post gerade noch einmal gelesen.
Websockets habe nichts mit TCP/UDP-Sockets zu tun, auch wenn du dort einen Signalig-Channel hast, dessen verhandlungen als ein Handshake(von TCP/UDP-Sockets) betrachtet werden kann.
 
Zuletzt bearbeitet von einem Moderator:
Das du Applikationen schreibst die dem ersten Anscheinen nach produktiv eingesetzt werden finde ich erschreckend.
Zum Vergrößern anklicken....
Würdest Du mir diese Aussage bitte etwas genauer erklären

Apache kann IMO keine Websockets.
Zum Vergrößern anklicken....
Das erklärt das ich nichts gefunden habe und deswegen hier frage ...

Für Peer-2-Peer-Verbindungen brauchst du auch keine, denn der Signaling-Channel kann eine xbeliebige/s Protokoll/Technologie haben.
Es ist also wichtig wofür du die Websockets einsetzten möchtest.
Zum Vergrößern anklicken....
Ist das Websocket nicht nur auf das HTTP Protokoll aufgesetzt und erweitert dieses ?



Hab deinen Post gerade noch einmal gelesen.
Websockets habe nichts mit TCP/UDP-Sockets zu tun, auch wenn du dort einen Signalig-Channel hast, dessen verhandlungen als ein Handshake(von TCP/UDP-Sockets) betrachtet werden kann.
Zum Vergrößern anklicken....

Ok, weil man nur messages versendet und keine bytestreams ... , sry, pakete
 
Zuletzt bearbeitet:
Würdest Du mir diese Aussage bitte etwas genauer erklären
Zum Vergrößern anklicken....

Du schreibst Systeme(welcher Art auch immer) für Unternehmen(welcher Art auch immer), sonst würdest du hier nicht nach Entlastung fragen.
Speziell das "unsere Applikation" impliziert das.

Du hast offensichtlich nicht wirklich viel Einsicht in die Materie.

Es ist keine Schande nicht alles zu wissen. Teufel auch ich stelle mich manchmal total dämlich an, aber ich würde niemals auf die Idee kommen auf etwas zu setzten, von dem ich gehört habe, ohne mich vorher damit näher auseinander zu setzten, und dazu gehört auch das man Websockets nicht mit TPC/UDP-Sockets vergleicht, und zumindest weiss das NodeJS ein Server ist und nichts mit dem Client zu tun hat.

Was aber Vorbildlich ist, ist das du Nachfragst :D


Ist das Websocket nicht nur auf das HTTP Protokoll aufgesetzt und erweitert dieses ?
Zum Vergrößern anklicken....

Die eigentliche Kommunikation mittels Websocket: Ja.
Die Verhandlungen die diesem Verbindungsaufbau vorausgehen: Nein.
Deshalb könntest du auch mit Apache als STUN-Server einen Peer-2-Peer-Verbindung mit Websockets realisieren.
Als TURN-Server wird es schon etwas schwieriger.


Edit:
Der Unterschied zwischen Websockets und TCP/UDP-Sockets hat etwas mit der Anwendungsschicht zu tun(siehe OSI).
Websockets selbst sind Frame-basiert was IMHO vergleichbar mit den Frames von TCP/UDP-Sockets ist.
 
Zuletzt bearbeitet von einem Moderator:
Zitat:
Würdest Du mir diese Aussage bitte etwas genauer erklären
Du schreibst Systeme(welcher Art auch immer) für Unternehmen(welcher Art auch immer), sonst würdest du hier nicht nach Entlastung fragen.
Speziell das "unsere Applikation" impliziert das.

Du hast offensichtlich nicht wirklich viel Einsicht in die Materie.
Zum Vergrößern anklicken....
ich denke das Deine Aussage bezogen auf Sockets, in Verbindung mit dem WWW, Neuland für mich sind, stimmt.

Und darauf gesetzt wurde noch nicht!

Jedoch

Es ist keine Schande nicht alles zu wissen. Teufel auch ich stelle mich manchmal total dämlich an, aber ich würde niemals auf die Idee kommen auf etwas zu setzten, von dem ich gehört habe, ohne mich vorher damit näher auseinander zu setzten, und dazu gehört auch das man Websockets nicht mit TPC/UDP-Sockets vergleicht, und zumindest weiss das NodeJS ein Server ist und nichts mit dem Client zu tun hat.
Zum Vergrößern anklicken....
guckst Du hier ...

Noch dazu hat ByteSurfer sich ein Buch gekauft, um hier die Basics 2014
aufzufrischen ... ;)
Zum Vergrößern anklicken....
Ein Polling via Ajax ist nicht die perfomanteste Lösung, deswegen wurde von mir nach einer Alternative gesucht. Hier war und ist weiterhin das "Websocket" im Vordergrund.

aber ich würde niemals auf die Idee kommen auf etwas zu setzten, von dem ich gehört habe, ohne mich vorher damit näher auseinander zu setzten,
Zum Vergrößern anklicken....
Deswegen recherchiert man und bildet sich weiter ... Gerade in der Programmierung sollte so etwas eine Grunsvorraussetzung sein ... Und sich bilden und weiterentwickeln kann man nur auf Basis von Fragen, Gesprächen, testen, spielen und auch lesen ...

unabhängig von den jeweiligen Vorkenntnissen ...

Aufgrund Deiner Anmerkungen, Aussagen stelle ich für mich aber fest hier doch mehr Nachholbedarf zu haben als geglaubt bzw. erhofft ...

P.S.: Nicht immer so schnell den "verbalen Revolver" auspacken ;)
 
Ja, wenn du es so gestaltest habe ich definitiv über das Ziel hinausgeschossen.
Tut mir leid.

Gruß

Fluffy

Edit:
Also, was sind die näheren Eckdaten bzgl. des Einsatzszenarios, also wo willst du das Polling ersetzten? Damit wir das auch Themenbezogen abschließen können.
 
In einer bestehenden Webapplikation (Intranet) wird bei einer bestimmten Situation vom Browser ein Job angestossen, welcher teilweise (Serverseitig) viel Zeit in Anspruch nimmt.

Aufgrund dessen enstanden hier ein paar "Zwickmühlen":

1. zum einen lief der Browser in den Timeout
- ändern der diversen Einträge in der Browserkonfig war erfolglos
2. desweiteren schloss der Server den Prozess ab, jedoch ohne Info, nach Abschluss, an den entsprechenden Nutzer.

Eigentlich absolut inakzeptabel ....

Um das ganze abzufangen stelle ich alle X-Sekunden eine Anfrage via Ajax an den Server um hier den Timeout zu verhindern.

Funktioniert, ist aber echt "*'@%?"

Deswegen, will ich das ganze in eine andere Richtung schieben und besser lösen.

Da über eine Socketverbindung auch Serverseitig gepusht werden kann, dachte ich der Browser sendet den Auftrag ab und wartet am Port X auf Informationen, Nachrichten, Json.successful wie auch immer vom Server.

Mein bisherige Kenntnisstand sagt, das durch ein Socket (Listen an Port XYZ) der Browser die Verbindung am leben hält und somit nicht in den Timeout läuft. Zuzüglich wird das Netzwerk nicht mehr so extrem belastet.

Ich hoffe mein philosophischer Gedanke ist nicht gänzlich verkehrt ?
 
Das hört sich für mich nicht nach einem Problem an was du mit Websockets primär beheben kannst.
Es würde nur die Symptome kaschieren.
Hört sich für mich also eher nach einem Architekturproblem an.

Punkt1 hört sich für mich danach an, das der Server anfägt zu arbeiten aber nichts zurückliefert.
Normalerweise wird bei entsprechender Konfiguration die Verbindung am Leben gehalten.

Punkt2 müsstest du sagen was "Keine Informationen" bedeutet.
Du musst dir in diesem Punkt auch sicher sein das die Aufgabe wirklich abgearbeitet ist.
Sonst kann es sein das z.B. ein PHP-Skript das zeitliche Limit für die Ausführung überschreitet und einfach stirbt.

Aber dafür müsstest du mehr Informationen über den Techstack geben.
Im Intranet selbst hast du ja 100Mbit und mehr, eine Statusabfrage selbst wird, als Antwort nicht so viele Informationen enthalten.
Es ist also eine komische Optimierung, wenn man das ganze nur von Netzwerkseite betrachtet, wie du es machst(zumindest von der Argumentation her), Softwaretechnisch(CPU-Cycles, etc) ist das was anderes.

Bzgl deiner WebsocketIdee, deine Idee kann funktionieren, und ich lege dir in diesem Fall SocketIO ans Herzen, da ich jetzt einfach mal NodeJS annehme, ob das in die bestehende Architektur/Struktur reinpasst, weiss ich nicht, zu wenig Infos.

Gruß

Fluffy
 
Zuletzt bearbeitet von einem Moderator:
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben