ugrás a tartalomhoz

A websocket vajon mi? :)

mind1 valami név · 2018. Dec. 27. (Cs), 10.47
Szóval mi is ez tulajdonképp?
O.K., addig tiszta, hogy egy kétirányú/duplex kommunikációra alkalmas eszköz.
De mitől "web"?
Amit eddig láttam belőle, annak alapján ugyanolyannak tűnik, mint bármely más socketes kommunikáció.

ui: ha a cím ismerős lenne valahonnan... https://www.youtube.com/watch?v=6aabdiJkxcw (de óvatosan, a megnyitás agykárosodást okozhat! ;) )
‹ Kliens IP címe Hogyan mondanátok, hogy garantált/ellenőrzött a környezet? ›
 ■
1

Websocket

Poetro · 2018. Dec. 27. (Cs), 11.02
Attól web, hogy ez egy webes szabvány, és a mai böngészők támogatják is a használatát. Azaz a böngésző tudja mi az, és JavaScripttel lehet adatokat küldeni és fogadni a csatornán.
2

Nem pont erre gondoltam, ez

mind1 valami név · 2018. Dec. 27. (Cs), 14.19
Nem pont erre gondoltam, ez egyértelmű volt eddig is, de rosszul is tettem fel a kérdést.
Próbálom másképp, bár ez sem biztos, hogy közelebb visz: alapjáraton socket alapú kommunikáció felületes megfogalmazásban kb. annyit jelent, hogy a szerver megnyit egy tcp/udp portot vagy unix socketet, a kliens csatlakozik hozzá, majd ezen át elkezdenek kommunikálni, tetszőleges "nyelven".
Itt is ez van, csak a böngészők fel vannak készítve rá és pl. JS használatával gyakorlatilag ugyanezt a kommunikációt teszik lehetővé? Vagy van valami saját protokoll aminek meg kell felelni, ha websocketen próbálok társalogni a szerverrel?
Netán a http/https felett működik?

Ha egy oldalt https-n nyitok meg, akkor az így letöltött oldal javascriptjei egyértelműen SSL-t használnak websocketen is? Vagy az totál független tőle?

Nézegettem minta programokat, wikit, de valahogy nem áll össze a kép.
3

Nem HTTPn keresztül működik

inf · 2018. Dec. 28. (P), 00.01
Nem HTTPn keresztül működik amennyire én tudom. Van külön WSS, ami titkosított, azt kell használni. https://devcenter.heroku.com/articles/websocket-security
https://en.wikipedia.org/wiki/WebSocket
https://tools.ietf.org/html/rfc6455
4

handshake vagymi az még http, nem?

Arnold Layne · 2018. Dec. 28. (P), 00.42
Jó, de amiket linkeltél, abban is az van leírva, hogy az elején rövid ideig még a HTTP-t beszélik, aztán amint mindkét fél meggyőződött arról, hogy a másik érti a websocket, onnantól úgy folytatják. Az megint más, hogy a JS ezt elfedi egy ojjektum példányosításával.
6

Amennyire értem a wikit,

mind1 valami név · 2018. Dec. 28. (P), 10.22
Amennyire értem a wikit, rfc-t, a http csak addig tart, míg a kliens és a szerver megbeszélik, hogy mindketten kezelik a websocketet. Maga a websocket már önálló kommunikáció, ami egy kulcscserét is tartalmazó handshake-kel indul ténylegesen.

Mondjuk ezt is egyre nehezebben tudom megemészteni: van valami kapocs a http session és a websocketes kommunikáció között? (magyarán: az adott ws kommunikációnál a szerver mindig biztos lehet abban, hogy a kliense valóban az, akinek mondja magát? - már olyan szinten, ahogy pl. http esetén a session cookie-k alapján azonosítja)
7

This can be done in a variety

inf · 2018. Dec. 28. (P), 12.08
This can be done in a variety of ways, as WebSockets will pass through standard HTTP headers commonly used for authentication. This means you could use the same authentication mechanism you’re using for your web views on WebSocket connections as well.

Since you cannot customize WebSocket headers from JavaScript, you’re limited to the “implicit” auth (i.e. Basic or cookies) that’s sent from the browser. Further, it’s common to have the server that handles WebSockets be completely separate from the one handling “normal” HTTP requests. This can make shared authorization headers difficult or impossible.

...

https://devcenter.heroku.com/articles/websocket-security#authentication-authorization
5

A wikinek lehet még hinni?

mind1 valami név · 2018. Dec. 28. (P), 02.23
A wikinek lehet még hinni? Úgy értem, ennek a cikknek?
Átfutottam rajta pár napja, de ősi böngésző verziókat emleget a magyar és az angol is, emiatt hagytam is a fenébe, mondván, elavult infókat tartalmaz.
8

O.K., valami halovány

mind1 valami név · 2018. Dec. 31. (H), 17.05
O.K., valami halovány elképzelésem már van a websocketről, miután kicsit kibeleztem a talált példakódokat is.
(nem tudom, mennyire közismert, hogy a pythonra vagyok rákattanva, ami azért elég távol áll a javascripttől és php-tól)

Viszont most ott tartok, ahonnan indultam (ami kimaradt a nyitó hozzászólásból egyébként), hogy akkor ez most végül is miért lenne jó nekem a unix socket helyett?
Nem vagyok kötve sem web szerverhez, sem webes kliensekhez, ennek ellenére valaki (már meg nem mondom, hogy hol :( ) azt javasolta, hogy hagyjam a fenébe a normál socketeket, használjam ezt.
De mi előnyöm származik a használatából, ha olyasmire használom, amihez nem kell webes kliensből hozzáférni?

ui: bocs, ha fárasztóak a kérdéseim, egyre nehezebben olvasok sajnos - egy-két soros üzenetekkel még nincs gond, de hosszabb doksikkal már nem nagyon boldogulok még magyarul sem.
9

Ha nem kell webes kliens,

inf · 2018. Dec. 31. (H), 18.30
Ha nem kell webes kliens, akkor nincs értelme. Én úgy tolom, hogy minden webservice, websocket, stb. amit itthonra csinálok, inkább GUI-ban szeretem megoldani a dolgokat, mint CLI-ben.
10

Webes kliens nem kell.

mind1 valami név · 2018. Dec. 31. (H), 19.09
Webes kliens nem kell. Ráadásul pythonban a websockets modul asyncio-t használ, ami végképp nem teszi egyszerűvé az életet. :)