- 2208 ako ZV pred chvilkou skoncil celoranu spicku na linke 83/10 ( povodne mal ist 2404 - mozno popoludni pojde )
- 2109 prave v Dubravke na linke 83/3 taktiez ako ZV za 2823, ktory vypadol po 8. h.
Dalsie informacie az vecer
- 2109 prave v Dubravke na linke 83/3 taktiez ako ZV za 2823, ktory vypadol po 8. h.
Dalsie informacie az vecer
To su pekne spomienky, skoda ze sa taka 14Tr nezachovala. Bol by to dnes unikat!
Dalej si pamatam na linke 10 a 14 este "tee dvojky". Btw., hlasili aj Ikarusy???
si
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.