<div dir="ltr"><div><div><div><div><div>Nem, a mérleg egyik oldalán ez van:<br>"lényeg hogy TCP-s kommunikációt szeretnék egy szerverrel -> Most
WebSocket, kicsit később pedig HTTP/2, ha elterjed... minden más csak
önszopatás, kivéve, ha valami nagyon ritka és speciális okból nem
megfelelő a WebSocket..."<br><br></div>A másik oldalán meg az, hogy a WebSocket nem univerzális megoldás, és nem csak nagyon ritka és speciális esetekben nem megfelelő. <br></div>Ahogy azt többször is leírtam, nem minden proxy engedi át, és nem minden fogja átengedni. S ugyanazt fogják mondani a proxy üzemeltető rendszergazdák, mint amit 15 éve a HTTP CONNECT metódusára (ami kb hasonló dologra jó)<br></div> - a tűzfal/proxy nem támogatja<br></div> - a tűzfal/proxy nem támogatja, egy későbbi verziója fogja, de arra meg nem upgradelhetünk, mivel ...<br></div><div> - stb ...<br></div> - egyébként is, egy bináris protokolt nem engedünk át a tűzfalon, mert céges policy ...<br><div><div><div><div><br><br></div><div>Véleményem szerint, ha két különböző gépen levő programnak kell kommunikálnia egymással, akkor a legritkább esetben szükséges egy új protokoll, byte szintű leimplementálása, sokkal egyszerűbb, ha választ egy már létező protokollt, és egy azzal működő kliens és szerver könyvtárat, ami magas szinten kezeli ezt a kommunikációt. Legyen az SOAP-RPC, vagy Kafka, vagy Hazelcast, vagy AMQP kliens, stb.<br></div><div>Igen, ezek plusz rétegek lesznek a programban, de ezek a rétegek adnak is valami funkcionalitást a programhoz, nem csak annyit, hogy a hagyományos socket réteg felé rak egy másik réteget, ami becsomagolja http- be, és vagy működik vagy sem.<br><br><br></div><div>Üdv<br><br></div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-19 16:45 GMT+01:00 Gábor Auth <span dir="ltr"><<a href="mailto:auth.gabor@gmail.com" target="_blank">auth.gabor@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Ahol megy a http, nem feltétlenül megy a websocket, pont ahogy a bináris socketnél sem.</div></div></div></blockquote><div><br></div></span><div>Akkor álljunk meg egy szóra: mi van a mérleg két oldalán? Nálam a bináris Socket vs WebSocket.</div><div><br></div><div>Nálad - úgy érzem - éppen az van a mérleg másik oldalán, ami az adott és/vagy vitatott pontban jobb, ugyanis nem jó a WebSocket, mert:</div><div>- nem megy át HTTP proxy-n: de átmegy, ahol nem megy, ott más se megy át, erről szól a proxy és a security by design.</div><div>- kell hozzá kliens lib: SOAP-ot, MQTT-t vagy Redis-t fejből és nulláról implementáltál?</div><div>- több réteg kell hozzá: mert az MQTT, a SOAP vagy az AQMP hány rétegű?</div><div>- kommunikációs overhead: mert a többinél nincs?</div><div><br></div><div>Egy kérdést teszek fel: mi az a megoldás, ami össze tud kötni két gépet full duplex, átmegy HTTP/1.1 proxy-n és nem kell hozzá kliens library?</div><div><br></div><div>Egyébként felőlem mindenki azzal szív, amivel akar, én több ezer telefonról használok jelenleg is WebSocket kommunikációt gond nélkül, gondoltam leírom, hogy mennyire egyszerű.</div><div><br></div><div>Bye,</div><div>Auth Gábor</div></div></div></div>
<br>_______________________________________________<br>
Javalist mailing list<br>
<a href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
<a href="http://lists.javaforum.hu/mailman/listinfo/javalist" rel="noreferrer" target="_blank">http://lists.javaforum.hu/mailman/listinfo/javalist</a><br>
<br></blockquote></div><br></div>