[Javalist] java socket multiple request

[bognár attila]

Szia,

> Ugyanazokkal az eszközökkel, mint a HTTP-t, mert arról ugrik, szóval 
> ott vannak a HTTP fejlécek, a kikényszeríthető SSL, a 
> certification-ök, a timeout és minden más, amit a HTTP(S) alapból tud. 
> Ha azt mondod, hogy nincs eszközparkban különbség a HTTP(S) alapú 
> protokoll és egy szimpla bináris TCP socket között, akkor az egy rossz 
> eszköz, nem képes ellátni a feladatát.

(Gondolom nem SSL-t, hanem TLS-t szeretnél kikényszeríteni. TLS nem csak 
HTTP alatt van.)

Idéznélek:
"Vagy valami egyéb elképzelés, ami o-o-t-b helyettesíti a bináris 
socket-et és átmegy mindenféle proxy-n?"
"Ha odamész a hálózatosokhoz, hogy Neked kellene egy bináris egyedi 
socket két gép között, akkor a minimum az, hogy leakasztják a korbácsot, 
mert nincs dobozos szoftverük arra, hogy ezt a forgalmat szűrni, 
ellenőrizni, engedélyezni és tiltani tudják."

Lehet, hogy elbeszélünk egymás mellett.

Mit értesz szűrés, ellenőrzés alatt?
Tudnál példát írni, hogy milyen WebSocket kommunikációt, milyen 
tűzfallal, miként lehet szűrni, milyen célból?
Például:
- csak adott alkalmazást szeretnél átengedni
- kapcsolatot ki szeretnéd lőni, ha béradatok mennek ki
- kapcsolatot ki szeretnéd lőni, ha üzleti tervek mennek ki
- egyik alkalmazásnak csak bizonyos funkciója érhető el

Mint írtam, nem használtam még WebSocketet, de érdekel(t), valamennyit 
olvasgattam gyorsan róla, az alapján úgy tűnik, hogy elég nagy szabadság 
van a protokoll vonatkozásában (kvázi bármit tudsz küldeni értelmezésem 
szerint). Mind szintaktikailag, mind szemantikailag, innentől kezdve nem 
világos, hogy mi az, amiért egy hálózatos jobban örül, ha egy WebSocket 
forgalmat kell kezelnie, illetve miért tud jobban kezelni egy WebSocket 
forgalmat, mint valamilyen más protokollt, másik porton.


>
> Na, ezért különösen jó, hogy hozzászóltok a WebSocket témájához, pedig 
> nem is használjátok aktívan... :D

Infrastruktúra vonatkozását hoztam elő, a HTTP jellege alapján úgy 
gondolom van annyi tapasztalatom, hogy hozzá tudjak szólni egy gondolatnyit.
Ha a szemléleted szerint mindig csak a valamilyen szempontból 
tapasztaltabb juthat szóhoz, akkor belátható módon sose lesz semmilyen 
eszmecsere.


>     Amire én tettem a megjegyzést: szépen becsomagolták HTTP jellegű
>     forgalomba, hogy jobban át lehessen menni a tűzfalakon, holott ezt
>     a funkcionalitást nemcsak HTTP jelleggel lehetett volna megoldani).
>
>
> A tervezési cél nem az volt, hogy át tudjon menni a proxy szervereken...

https://tools.ietf.org/html/rfc6455: "The goal of this technology is to 
provide a mechanism for browser-based applications that need two-way 
communication with servers..."
Ez alapján úgy gondolom, hogy szempont volt, mivel a böngészős webnek 
részét képezik a proxy-k. Az RFC 15. oldalán le is írja a proxy kezelést.

Üdv,

Attila




--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20160120/753cab4e/attachment.html>