[Javalist] java socket multiple request

[Zsombor]

2016-01-19 15:23 GMT+01:00 Gábor Auth <auth.gabor at gmail.com>:

> Hi,
>
> Tehát ha http-felett megpróbálunk websocket-t, és azon felül még egy saját
>> protokollt, az biztos kevesebb munkával és önszopatással jár, mintha bármi
>> mást teszünk?
>>
>
> Ahol megy a WebSocket, ott nem biztos, hogy megy bármi egyéb... ahol megy
> a bináris socket, ott megy a WebSocket is.
>
>
Ahol megy a http, nem feltétlenül megy a websocket, pont ahogy a bináris
socketnél sem. Nem véletlenül szoktak alternatív megoldásokat használni ott
is, ahol a böngészőből próbálnak websocketet használni.


> Pontosan, szóval miért is jó a websocket?
>>
>
> Mert ha mégis ott van egy proxy, akkor azon jó eséllyel átmegy. Az általad
> felsoroltak közül a SOAP megy át a proxy-n (mondjuk az se találja ki
> magától), de az meg nem full duplex.
>

A "jó esély" az helyzete válogatja. A tapasztalataim szerint, ha nincsen
proxy, akkor működhet, ha van, akkor az úgy szívás.


>
>
>> Nem, de plusz két réteg beiktatása miért is tenné könnyebbé az életet
>> mindig?
>>
>
> Nincs plusz két réteg...
>
>
De, van egy http réteg, rajta a websocket réteg, és afölé kapsz egy
"bináris socketet" - ok, némi frameinggel.



> Nyilván mindegyik tökéletes, és könnyen használható, és jól kitalálja a
>> helyi proxy beállításokat :)
>>
>
> Legalább annyira jól kitalálja a helyi proxy beállításokat, mint a bináris
> socket vagy az MQTT... oh wait, a socket át se megy a proxy-n az MQTT pedig
> HTTP over WebSocket alapú lesz... oh wait, a WebSocket nem jó!
>
>

Örülök, hogy végre látod, hogy a websocket pont olyan jó mint az alacsony
szintű socket !




> A kérdés onnan indult, hogy valaki akart két gép között üzeneteket
>> cserélni.
>>
>
> Igen.
>
>
>>  * overkill (pl ugyanazon az intraneten kell működnie),
>>
>
> Mi az overkill? Komolyan érdekel, mert ugyanannyi sor a WebSocket
> létrehozása kliens és szerver oldalon mint egy bináris socket létrehozása
> és a HTTP upgrade után nincs overhead.
>


Az overkill alatt a plusz libek és kommunikációs overheadet értettem.



>
>
>>  * nem működik - a proxyk pont úgy vannak konfigurálva, hogy nem engedik
>>
>
> Miért, mit engednek, ami full duplex bináris protokoll? Egy valamit mondj
> már, az előbb is kérdeztem. Annyira kapaszkodsz ebbe a proxy dologba, hogy
> kezdtem azt hinni, van megoldásod, de nincs...
>

Nem, még egyszer elmondom : ha van proxy, akkor bármi, ami a http/1.1-nél
bonyolultabb, jó eséllyel nem fog menni. Felesleges is ragaszkodnod a
WebSocket-hez, hogy az az univerzális megoldás mindenre, mivel nem az.



>
>
>>  * túl bonyolult - fölötte úgy is meg kell csinálni egy saját protokollt.
>>
>
> Pont annyira kell felette saját protokollt csinálni, mit a socket fölé.
>

Örülök, hogy látod, hogy mennyire nem segít a WebSocket ebben sem.



>
> Adott esetben jól működhet a SOAP-tól kezdve a Burlap/Hessian vagy
>> szimplán a jó öreg REST/JSON,
>>
>
> Ezek egyike se full duplex, nem alkalmas a WebSocket kiváltására.
>


Mivel mindegyik már előbb volt mint a WebSocket, sosem volt céljuk a
kiváltása :)
Amúgy SOAP-pal simán full duplexül is kommunikálni, vannak cégek ahol
Kerberos-os authentikációs-soap üzengetős alkalmazásokat építgetnek dögivel
;)



>
>
>> de meg lehet nézni az MQTT-t, AMQP-t, STOMP-ot ha pub-sub rendszert
>> szeretnénk elsősorban,
>>
>
> Ezek vagy nem mennek át proxy-n vagy szintén nem full duplex megoldások.
>

vagy akár a Redis vagy a Memcached protokolját is,
>>
>
> Óh, szóval a Redis kommunikációs protokollja egyszerűbb, mint a WebSocket?
>
>
Utolsó emlékem szerint elég egyszerű volt a Redis protokolja, bár annyira
nem emlékszem, memcached szervert már csináltam, mivel voltak (buta) kliens
programok, amik azt beszélték - s nem volt bonyolult. S eszembe nem jutott,
hogy WebSocket-tel kezdjek bele :)



> Komolyan arról beszélünk, hogy például az alábbi kódrészlet összetett? :O
>
> AsyncHttpClient.getDefaultInstance().websocket("ws://...", "ws",
>                     new AsyncHttpClient.WebSocketConnectCallback() {
> //...
> });
>
>
Nem.


Üdv
 Zs
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20160119/45d84430/attachment.html>