nicht angemeldet
Vorteile von Websockets
0 0 0 0
Vorteile von Websockets
Hallo.
Mit HTML5&Co sollen ja auch Websockets Einzug in JavaScript erhalten.
Aber kann man nicht jetzt schon die Funktionalität von PUSH-Ereignissen erreichen in dem man einen XMLHttpRequest verwendet und der Server den Request einfach offen hält und die Daten erst sendet/streamt wenn ein Ereignis eintritt?
Wo bieten Websockets Vorteile, bzw. welche Nachteile hat ein XMLHttpRequest?
Grüße,
Thomas
-
WebSockets haben im Wesentlichen den Vorteil, dass der Port gepollt werden kann und nicht die ganze Zeit offen bleiben muss.
Gruß, LX
--
RFC 1925, Satz 2: Egal, wie fest man schiebt, ganz gleich, wie hoch die Priorität ist, man kann die Lichtgeschwindigkeit nicht erhöhen. -
hi,
Wo bieten Websockets Vorteile, bzw. welche Nachteile hat ein XMLHttpRequest?
Maln doofes Beispiel, Ajax-Chat, Fred chatted mit Barney, jeder hat einen Browser. Fred schreibt was, Barney's Browser muss ständig pollen (sagen wir, alle 3 sekunden), um zu sehen, ob Fred was geschrieben hat.
WS-Chat, Fred schreibt was in seinen WS-fähigen Browser, der schickts zum Server und der Server schickts zu Barney. Barney's Browser muss also nicht ständig nachfragen, ob Fred was geschrieben hat, Barney's Browser kriegts geschickt.
Bei Ajax also bei einem Chat ständig Request/Response mit allen Overhead der dazugehört. Im WS jedoch wird _einmal die Verbindung ausgehandelt und dann gehts einfach hin-und-her, hat der Server was, schickt er es unvermittelt zum Client, ohne dass der nachfragen muss.
Für MultiMedia (Media Streaming) eröffnen sich da sicher neue Perspektiven, bleibt zu hoffen, dass die Clients mittlerweile auch Binaries verstehen ;-)
Hotti
-
Hallo.
Aber das Szenario lässt sich doch bereits mit XHR umsetzen.
Der Client baut den Request zum Server auf und dieser streamt die Daten dann. Der Server muss die Verbindung einfach nicht schließen.
Mit PHP ist dass allerdings wirklich nicht so einfach möglich. Da müsste man schon eine while-Schleife erstellen, die ständig prüft ob es neue Ereignisse gibt und diese dann ausgeben (sehr hässliche Lösung). Aber es gibt ja nicht nur PHP...Thomas
-
hi,
Aber das Szenario lässt sich doch bereits mit XHR umsetzen.
Der Chat nicht, Unterschiede siehe mein Post.
Der Client baut den Request zum Server auf und dieser streamt die Daten dann. Der Server muss die Verbindung einfach nicht schließen.
Streamen, ja, da hast Du recht.
Mit PHP ist dass allerdings wirklich nicht so einfach möglich.
Nunja, socket_read($socket, $length, PHP_BINARY_READ); will eine Längenangabe. Aber was spricht dagegen, $length auf 4 GB zu setzen, da läuft ein per HTTP-Request angeforderter MP3-Steam lange genug ;-)
Was ich mir evntl. für WS noch gut vorstellen kann, ist eine Bilder-Show quasi als Serverpush, oder ums mal konkret zu machen: Viele Einzelbilder (ab 25/s), die dann einen Film ergeben.
Hotti
-
Tach auch.
Aber das Szenario lässt sich doch bereits mit XHR umsetzen.
Der Chat nicht, Unterschiede siehe mein Post.Da ich bereits einmal einen Chat entsprechend implementiert habe (zugegebenermaßen aber nur zu Testzwecken), kann ich dir sagen: es geht.
Die Methode wird unter Anderem Comet genannt.
Im Prinzip sorgt der Client dafür, dass immer eine XHR-Connection offen ist. Der Server beantwortet diese einfach erst, wenn er Daten hat (in meinem Testchat hat er einfach jede Sekunde die Datenbank gecheckt, und nur wenn neue Daten da waren, hat er diese zurückgeschickt). Bekommt der Client eine Rückantwort, öffnet er sofort ein neues XHR.
Bis die Tage,
Matti-
Hi,
Aber das Szenario lässt sich doch bereits mit XHR umsetzen.
Der Chat nicht, Unterschiede siehe mein Post.Da ich bereits einmal einen Chat entsprechend implementiert habe (zugegebenermaßen aber nur zu Testzwecken), kann ich dir sagen: es geht.
Und mit WebSockets gehts sogar vernünftig, was meiner Meinung nach der Hauptvorteil daran ist.
~dave
-
hi Matti,
Die Methode wird unter Anderem Comet genannt.
Mit herkömmlichen XHR ist schon einiges möglich, ein wesentliches Manko besteht darin, dass Browser eine BINARY nicht unterstützen. Z.B. nach dem URL_Scheme data:image/jpg, da ist derzeit nur base64 möglich und das wird auch nicht von allen Browsern unterstützt. Sicher spielen da auch Machtkämpfe unter den Browserherstellern eine Rolle. Wenn es eine echte Binary-Unterstützung geben würde, bräuchte es nicht solche Krückenlösungen mit base64, es wäre ohne Weiteres möglich, ohne Flash o.a. Plugins einen Film zu zeigen, die Binary wird per asynchronen Request geladen und die Einzelbilder werden nach dem Preload als "Inline-Grafik" im entsprechenden Wechsel gezeigt.
Ähnliches ist sicher auch für Voice möglich. Sofern es eine binary-Unterstützung seitens JS geben würde, könnten Ajax-Responsen auch viel schlanker ausfallen, eine Strukturierung like JSON oder XML für Multipart-Content ist dann überflüssig, die Daten werden dann einfach nur serialisiert, genauso wie eine Binärdatei, die eine ganze Sammlung an Objekten enthalten kann in dichtester Packung.
Mit einem selbst konstruierten UA (Perl) ist es mir z.B. möglich, eine komplette Webseite (HTML) inclusive aller eingebauten Images als serialisierte Binary in einem POST zu meinem CMS auf den Server zu schicken, warum sollte das ein Browser von der Stange nicht können dürfen? Jetzt komm' mir bloß keiner mit multipart/form-data, wenn ich solchen Schrott sehe, kann ich nur müde lächeln, das kommt mir vor wie eine Elektroinstallation mit freien Kupferleitungen auf Keramik innerhalb meiner Wohnstube, wohl aus der Zeit, als es noch keine geeigneten Kunstoffe gab, um ein Kabel einzugießen.
Wir müssen einfach mal abwarten, was die Zeit bringt und werden dann immer noch ein Eckchen finden, wo wir mal wieder was programmieren dürfen ;-)
Hotti
-
Hi zusammen!
Die Methode wird unter Anderem Comet genannt.
Danke. Habe es schon oft so gemacht aber wusste nicht, dass das ganze auch einen Namen hat ;)
Mit herkömmlichen XHR ist schon einiges möglich, ein wesentliches Manko besteht darin, dass Browser eine BINARY nicht unterstützen.
xhr.overrideMimeType('text/plain; charset=x-user-defined') behebt dieses Problem (in einigen Browsern). Die anderen haben hoffentlich responseBody mit an Board (u.a. IE>=7 wenn ich mich richtig erinnere).
Grüße,
Thomas
-
-
Hi nochmals,
Die Methode wird unter Anderem Comet genannt.
Habe Folgendes in der HTTP 1.1 specification gefunden (stand auch im Wiki-Eintrag):
"A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4)In Opera kann man das angeben und da liegt die Vorgabe bei 16 Verbindungen pro Server, also scheint der sich per Default nicht dran zu halten.
Weiß jemand wie sich das bei den anderen Browsern verhält?Thomas
-
Hallo,
Habe Folgendes in der HTTP 1.1 specification gefunden (stand auch im Wiki-Eintrag):
"A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy."
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4)In Opera kann man das angeben und da liegt die Vorgabe bei 16 Verbindungen pro Server, also scheint der sich per Default nicht dran zu halten.
Weiß jemand wie sich das bei den anderen Browsern verhält?Firefox: http://kb.mozillazine.org/Network.http.max-connections-per-server
Freundliche Grüße
Vinzenz
-
Hi,
Firefox: http://kb.mozillazine.org/Network.http.max-connections-per-server
Danke.
Habe eben noch die Werte für IE + Chrome gefunden, also nochmal die komplette Liste für Leute die eventuell die gleiche Frage haben:
Verbindungen die der Browser pro Server zulässt:
Firefox bis Version 2: 8 Verbindungen
Firefox ab Version 3: 15 Verbindungen
siehe http://kb.mozillazine.org/Network.http.max-connections-per-serverOpera bis Version 9: 8 Verbindungen
Opera ab Version 10: 16 Verbindungen
siehe in Opera: Einstellungen -> Erweitert -> NetzwerkChrome: 6 Verbindungen (nicht veränderbar)
siehe Diskussion der Entwickler: http://code.google.com/p/chromium/issues/detail?id=12066IE (bis IE 8?): 2 Verbindungen (Wert kann über die Registry geändert werden)
siehe http://support.microsoft.com/kb/282402Grüße,
Thomas-
Nochmals hallo.
Kennt zufällig noch jemand den Wert für Safari?
Eventuell für mobile Browser wie iPhone/iPod/Android browser?Thomas
-
-
-
-
-
-
-