Marki: nie je to ani neak zlozite, ak sa ti chce troska programovat a pozerat co ti wap dovoli a co nie. Princip vyzera nasledovne:
na strane klienta (teda teba s mobilom a PC) sprvis SW, ktory bude generovat requesty na neaku wapstranku (ktora v skutocnosti wapstrankou nebude) asi v nasledujucom formate: http://wap.tvojadomena.sk/DATA kde DATA su samotne prenasane packety od teba. Je nevyhnutne zabezpecit aby ziaden z requestov nebol rovnaky (optimalne tam narvat timestamp, je to nutne napriklad aj kvoli cache ale aj kvoli identifikacii "packetov"), musis si zabezpecit encapsulaciu bajtov (pretoze ty mozes v packete posielat hocaky znak, ale http protokol (alebo cez aku pazu to ide) ti nedovoli do url-ka dat cokolvek a musis posielat requesty aj ked nic nechces (keepalive, aby si drzal linku zivu, lebo server ti nic poslat sam nevie).
strana "servera" bude prijmat prislusne requesty, spracovavat ich a posielat ti odpovede. Odpovede opat musis encapsulovat tak, aby ti to dovolil protokol preniest. (viacej sa mozme pobavit niekedy v reali, som lenivy vela pisat:-))
vyhody: pri dobrej implementacii ti to dokaze zabezpecit sice nekvalitnejsie, ale plnohodnotne spojenie na inet, pri vhodnej konfiguracii mozes mat doma aj verejnu IPcku a neaky server.
nevyhody: vysoky jalovy traffic, nutnost mat niekde vonku stroj ktory servuje requesty.
na strane klienta (teda teba s mobilom a PC) sprvis SW, ktory bude generovat requesty na neaku wapstranku (ktora v skutocnosti wapstrankou nebude) asi v nasledujucom formate: http://wap.tvojadomena.sk/DATA kde DATA su samotne prenasane packety od teba. Je nevyhnutne zabezpecit aby ziaden z requestov nebol rovnaky (optimalne tam narvat timestamp, je to nutne napriklad aj kvoli cache ale aj kvoli identifikacii "packetov"), musis si zabezpecit encapsulaciu bajtov (pretoze ty mozes v packete posielat hocaky znak, ale http protokol (alebo cez aku pazu to ide) ti nedovoli do url-ka dat cokolvek a musis posielat requesty aj ked nic nechces (keepalive, aby si drzal linku zivu, lebo server ti nic poslat sam nevie).
strana "servera" bude prijmat prislusne requesty, spracovavat ich a posielat ti odpovede. Odpovede opat musis encapsulovat tak, aby ti to dovolil protokol preniest. (viacej sa mozme pobavit niekedy v reali, som lenivy vela pisat:-))
vyhody: pri dobrej implementacii ti to dokaze zabezpecit sice nekvalitnejsie, ale plnohodnotne spojenie na inet, pri vhodnej konfiguracii mozes mat doma aj verejnu IPcku a neaky server.
nevyhody: vysoky jalovy traffic, nutnost mat niekde vonku stroj ktory servuje requesty.
COLOR