[Javalist] java socket multiple request

[bognár attila]

Szia,

>
>     Érthető. Erre mit csinál a szoftver fejlesztő? Mindent becsomagol
>     HTTP-be 80/443-as porton, merthogy az jobb eséllyel átmegy.
>
>
> Alapvetően nem a "jobb eséllyel átmegy" a vezérelv, hanem az, hogy a 
> felépített infrastruktúra meghágása nélkül tud működni és ugyanúgy 
> lehet szűrni, ellenőrizni, engedélyezni és tiltani, mint a http 
> forgalmat, mert tulajdonképpen http forgalom.

Miben tudod jobban szűrni, ellenőrizni?


> 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.

Engedélyezni és tiltani minden tűzfal tud. Ha nem tudna, akkor nem lenne 
tűzfal.
Szűrni, ellenőrizni akkor lehet valamit, ha ismered a kommunikációt. 
Attól, hogy WebSocketet használsz még, semmilyen "dobozos" tűzfal nem 
fogja tudni szűrni a forgalmat alkalmazás specifikus módon. Vannak 
UTM-ek, amik elterjedtebb protokollokat ismernek és tudnak szűrni, de ha 
Te készítesz valamit, azt jó eséllyel nem fogja tudni (két lehetőség 
marad: enged vagy tilt).
Legfeljebb örül a hálózatos, hogy nem kell foglalkoznia a kérdéssel, 
mert úgyse tudja szűrni (innentől kezdve az a kérdés, hogy miként 
engedik/tiltják a http-t, ami adott esetben más megítélés alá esik). 
Ellenben egy másik porton futó protokoll esetén írhatná a kérelmeket stb.

Nem ismerem a WebSocketet (nem használtam), ha jól értem a Wikipedia 
alapján az az elsődleges hozzáadott értéke, hogy folyam strukturálását 
teszi lehetővé (azaz tudod, hol kezdődik egy üzenet egység, hol 
végződik, duplex stb. ilyen alacsony szinttel nem kell foglalkoznod), 
ezt szabványosan. Ez teljesen rendben van.
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). Jó-jó, 
átmegy több helyen, csak kérdés, hogy ez mennyire megoldás.

Nekem ez olyan, mint a motoroknál alkalmazott turbó: kérdés, hogy a 
választott technológia mekkora távlatban értelmezhető válasznak. A 
motoroknál a turbó szerintem kényszer megoldás, az "apps over http" 
pedig kényelmi megoldás. Valahogyan működik, aminek működnie kell, de a 
valódi célhoz nem jutottunk közelebb.

Attila

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