Názory k článku Upozornění už vám mohou posílat i weby, dokonce i když je nemáte otevřené
-
Nenotifikovaný uživatel není žádný uživatel. Notifikovat by měl systém, nejlíp každá služba zvlášť a o všem, co se stane, samotné pc může notifikovat uživatele (jako třeba - byl zasunut konektor, opravdu chcete otevřít/zavřít program xyz, naše firma nesouhlasí s tím, jak spravujete svůj počítač atd.), každá stránka kterou jednou otevřete, by měla doživotně mít právo vám posílat notifikace. Za tím účelem by mohlo dojít k renesanci vyskakovacích oken (ale už by nebyly pop-up, ale push-up, takže by bylo všecno v pořádku), protože správná notifikace se nekrčí v koutku, ale přinutí usera, aby si jí všimnul.
-
_pepak (neregistrovaný)
Moc jsem z článku nepochytil, v čem je tato novinka přínosem proti existujícím RSS/ATOM. Podle popisu mi to přišlo jako úplně to samé, až na to, že u RSS/ATOM je přihlášení uživatele k odběru řešené technicky (uživatel si zařadí zdroj do čtečky), zatímco u Push notifikací doporučením webům, "aby to nabízely umírněně". Co přehlížím?
-
Tomáš Kapler (neregistrovaný)
Blbost - když si to neodsouhlasíte, tak na vás nic nevyskočí a kdykoliv to můžete snadno odvolat.
Naopak je to velmi užitečná služba, která eliminuje spoustu jednorázových udělátek (zhusta různě adware/virusware), které si člověk do počítačů instaluje, protože potřebuje třeba upozornit na novou poštu, novou zprávu na nějaké sociální síti atd. Vlastně se tím smazal poslední rozdíl mezi webovou službou a mobilní aplikací -
Koupili youtube: postujte videa, milí uživatelé, nic se nezměnilo, jenom se nám hezky zaregistrujte a udělte nám souhlas, že do budoucna užíváním teď už naší služby souhlasíte automaticky se vším. Další krok:
Teď nám sdělte jméno a další osobní údaje, ale nebojte, zůstane to soukromé. Další kolečko salámu:No a teď pro změnu můžete postnout videa a komentáře jen pod pravým jménem.
No a dále doba pokročila přátelé, takže si sjednoťte všechny účty pod svým pravým jménem a mimochodem možná o tom nevíte, ale zároveň jste se stali hrdými uživateli Google+.
(tu "real name policy" nakonec částečně vzdali, když jim začali utíkat lidi).
Nejsme evil, jenom normální podvodníci. -
Např. Gmail upozorňuje na novou poštu okýnkem vpravo dole na obrazovce bez jakéhokoliv doplňku. Jenže musí být spuštěn prohlížeč a načtený Gmail. Předpokládám, že platí i pro tuto technologii, že musí být spuštěný prohlížeč. Jediný bonus je, že nemusí být načtená příslušná stránka (chápu-li to správně).
-
lol (neregistrovaný)
ano, zaregistrujete workera (uzivatel to musi potvrdit). Ten pracuje na pozadi aj ked nie ste na stranke z ktorej ste si workera registrovali. Ten potom vie prijimat push a zobrazovat ich kedykolvek kedy je browser zapnuty.
Pouziva to notifikacne api - dalo by sa to riesit aj bez workera, ale uzivatel by musel mat konkretnu stranku otvorenu aby mohol prijimat notifikacie.
-
Například si zapnete, že chcete být upozorňován na nové e-maily. S RSS/ATOM by se nějaká služby musel dotazovat třeba každých 5 minut, zda není nový e-mail. Push notifikace se odešle v okamžiku, kdy e-mail přijde, tedy o něm víte okamžitě. Dřív to fungovalo tak, že jste musel mít v prohlížeči otevřenou příslušnou stránku, která notifikace posílala, dnes to jde i bez toho. Dokonce ani nemusí žádná webová stránka existovat – notifikaci vám může poslat třeba nějaké zařízení (kotel na chatě, že začal podle programu topit…).
V Androidu už to takhle funguje dávno, přesně z toho důvodu, aby se každá aplikace nemusela pořád dokola dotazovat na stav (a zbytečně tak probouzet mobil a spotřebovávat baterii) – místo toho se zaregistruje, že chce odebírat nějaké zprávy, a při změně stavu pak dostane zprávu o změně.
-
fd (neregistrovaný)
Mr jirsak, zjevne tedy zvanite a nevite o cem, nebylo by to porpve ze.
1) bud mam bezici aplikaci, ktera se aktivne dotazuje definovaneho serveru, zda nema nejaka data (pripadne minimalne musi udrzovat otevrenou konexi => bezet musi tak jako tak)
2) nebo mam server, ktery pasivne nasloucha na nejakem portu az mu prijde nejaky pozadavek. Ten hypoteticky bezet nemusi a nastartuje jej az nejake naslouchadlo reagujici na aktivitu daneho portu.
3) mam aplikaci, kterou mohu nadalku donutit k tomu, aby se pripojovala kam chci, coz je jeste o 10 radu horsi, nez ten naslouchajici server, protoze mi bohate staci derava aplikace a nemusim resit nejaky firewall.
Ale vy zjevne umite data prenaset teleportaci.
Mimochodem, presne takto se chovaji viry, stahuji si data bez vedomi uzivatele odkud se tvurci zrovna hodi a delaji, co se jim zrovna zachce.
-
fd (neregistrovaný)
Aha, vase skleroza nesaha ani o 3 posty zpet:
"S RSS/ATOM by se nějaká služby musel dotazovat třeba každých 5 minut, zda není nový e-mail. Push notifikace se odešle v okamžiku, kdy e-mail přijde, tedy o něm víte okamžitě. "
"přesně z toho důvodu, aby se každá aplikace nemusela pořád dokola dotazovat na stav"
-
Čemu přesně na tom nerozumíte? Když jste o novém e-mailu notifikován přes RSS, funguje to tak, že se klient připojí k serveru a zeptá se "neexistuje nějaký nový e-mail" (v RSS se ve skutečnosti ptá spíš na článek, pro notifikace o e-mailech Google RSS trošku zneužil), a server odpoví "ne, nic nového není". A za 5 minut (například) se klient ptá znova na to samé. Typicky se navíc ptá pokaždé v novém spojení, protože server pro RSS nebývá stavěn na to, aby udržoval spoustu neaktivních spojení.
Push notifikace přes GCM fungují jinak. Spojení naváže opět klient a sdělí serveru "až pro mne budeš mít nějakou zprávu, pošli mi jí". A tím to pro danou chvíli končí, server nic neposílá, když žádnou zprávu nemá, ale spojení zůstává otevřené. A když server dostane nějakou zprávu, kterou má klientovi doručit, pošle ji do toho pořád otevřeného spojení. Jediná komunikace navíc tam mohou být občasné pingy, aby se spojení udrželo otevřené.
Výhodou toho druhého řešení je, že když žádná zpráva pro klienta není, nic se neposílá, a že je to spojení navázané jen jedno a proudí přes něj zprávy pro všechny aplikace (na Androidu) a od všech webů (v Chrome). A pak samozřejmě také ta, že servery GCM jsou stavěné na to, aby zvládly spoustu dlouho otevřených spojení. -
Luk (neregistrovaný)
Podobně funguje například i rozšíření IDLE v poštovním protokolu IMAP. Poštovní klient (třeba Thunderbird, na androidím mobilu K-9 apod.) si otevře spojení na server, stáhne nové zprávy a pak pošle příkaz IDLE (jako že nemá co na práci). Jakmile přijde nová zpráva, pošle tím otevřeným spojením klientovi notifikaci, ten si pak hned novou zprávu stáhne. Není tedy potřeba čekat na nějakou periodickou kontrolu.
U webů běžně notifikace takhle samozřejmě nefungují, protože klasický protokol HTTP nic takového nepodporuje. Dělá se to tak, že se z JavaScriptu posílají ve vhodně zvolených periodách dotazy na server, jestli je něco nového. Zvlášť na mobilu je to průšvih, protože hlavně při komunikaci přes mobilní data (a zejména slabém signálu) to žere baterku jak divé.
-
lol (neregistrovaný)
http take nieco sice nepodporuje, ale websockety ktore nad http bezia nieco take samozrejme podporuju. Je to perzistentne stavove duplexne event-based spojenie nad neperzistentnym a nestavovym protokolom.
Baterku to ale bude zrat tak ci tak, kedze rezia za WS na urovni http je nepomerne vacsia ako u bezneho tcp socketu
-
Luk (neregistrovaný)
WebSocket neběží tak úplně nad HTTP (spíš by se dalo říct, že s ním sdílí TCP spojení a má jeho rysy, je to ale samostatný, trochu jinak fungující protokol), je relativní novinkou a například IE ho podporuje až od verze 10. Plus je samozřejmě potřeba řešit i serverovou stranu, např. modulem mod_pywebsocket do Apache (což není zrovna čisté řešení).
-
Pokud je bude každý web na který vstoupí pokaždé otravovat nabídkou "Povolte si u nás notifikaci, protože naše informace jsou ůůžasně důležité, ty musíte dostávat pořád i kdyby jste nechtěli" je opravdu potěší. :)
Mimochodem, docela by mne zajímalo, zda taková funkce bude možná pouze přímo z onoho zdrojového webu, a nebo bude možné řekněme i nabízet a zapínat přes odkazy na jiných webech, třeba skrze bannerové reklamy. Tím se podařilo internet zapráskat úplně.. -
Honza (neregistrovaný)
Tohle je hodne spatny krok, protoze je tim resen jen zajem guglu na jeho rust, ktery uz neni tak mozny pres vyhledavani, takze musi zvysit aktivitu a tim svuj rust prenesenim funkce na klienty. Ale bez ohledu na bezpecnost. Uz minuly rok bezpecnostni vyzkumnik Mariusz Mlynski prezentoval, jak lze push notifikace zneuzit k escalation utoku, https://www.mozilla.org/en-US/security/advisories/mfsa2014-42/. Takze uz tady nebude potencionalnich nekolik millionu web serveru nachylnych k utokum, kde alespon nejaci spravci kontroluji logy, hlidaji sec a delaji protiopratreni. Ale bude tady nekolik milliard klientu, kteri urcite nebudou tyhle opratreni delat. Gugl uz nevi jak by rostl a tak vymysli I tyhle koncepcne spatne protokoly. JInak Android neni vhodny priklad, protoze tam funguji notifikace jinak, jedna se o TCP socket propojeny z aplikace Google Play do GCM a tento socket je na klientovi v accept modu. To vetsina desktopovych fw zastavi a odstreli, ale Chrome si nastavi vyjimku a protuneluje fw. Kdyby tohle udelal MS, tak se vsadim, vsichni tady budou rvat o bezpecnosti, takze proc si tuhle prasarnu muze gugl dovolit? Je otazkou, jestli to udela stejne pres sockety nebo to udela jeste na http vrstve a bude na klientovi nejaky mikro-webserver. At tak ci tak, je to dira.
-
Honza (neregistrovaný)
Musíte se aktualizovat. Push notification je proprietarni standard Google pro Android, viz. http://developer.android.com/google/gcm/gcm.html a z něho je odvozený návrh na notifikace pro webové klienty a Chrome. Podobně je implementován v případě FF, viz. můj odkaz na prolomení, pouze se mluví o Notification API, ale jiná obálka je Push API, viz. http://www.w3.org/TR/push-api/. Ale je to vlastně úplně jedno, protože se jedná jen o XML vatu kolem, která má za úkol rozpoznat typ služby, ale fakticky to může být buď jen UDP komunikace nebo TCP, což by byl ten zmínění http. Nic jiného na tom nejde vymyslet a klient prostě musí mít službu/service/server/demon, která na tohle odpoví na tom portu a která musí být protunelovaná ven. Takže najednou máte miliardy vytunelovaných služeb, asi jako kdyby se každý klient by default šířil s nějakým skriptovaným a otevřeným peeringovým démonem. Pokud si nainstaluji P2P klienta a nechám ho otevřeného, jsem debil a nemůžu se divit, že pak mne někdo prolomí. Ale aby mi to by default nutil někdo jako gugl? To už je fakt nonsense.
-
Ano, jak jsem psal, píšete o úplně jiné technologii. To, co je použité v Chrome, je stejná technologie, která se používá na Androidu, tedy o Google Cloud Message - a tím končí to, co jste měl správně. GCM totiž funguje tak, že klient (Google Play, prohlížeč) naváže dlouhotrvající spojení k serveru GCM.
Nic jiného na tom nejde vymyslet
To, že vy nic jiného nedokážete vymyslet, neznamená, že to nedokázal někdo jiný. Navíc vaše řešení by stejně ve většině případů nefungovalo, protože klienti jsou za NATem nebo mají dynamickou adresu, takže by nebylo jak nebo kam navazovat spojení z venku. -
Honza (neregistrovaný)
Na GCM naváže GP socket spojení a je accept módu. A co asi je a bude u toho Chromu? To ten server bude na klienta posilat ty data nějak telepaticky?
A vymyslet nic jiného nejde, pokud se pohybujete v TCP/IP. Max můžete jít do P2P modelu, abyste protuneloval i ten NAT, ale to jsou dávno objevené metody firmama jako Kazaa, gnutela a další. Ale pořád to je jen v hranicích daných TCP/IP a jediné, co se liší je ta vata kolem. Není žádná magická koule, jak se snažíte naznačit. Ale to platí jen pro lidi, co o síťařině nemají žádnou znalost.
-
Přesně jak jsem psal v předchozím komentáři. V Chrome i Andoridu je to stejné, klient naváže TCP/IP spojení na GCM server. Není na tom nic magického, ani jsem nic takového nenaznačoval. Úplně stejně funguje i HTTP - tam také klient naváže spojení k serveru. Akorát HTTP spojení obvykle netrvá moc dlouho a po přenosu jednoho či několika souborů se uzavře. Takže žádné otevřené porty na klientovi, na které by se stejně nikdo nedostal, ani jiné vaše vynálezy, ale obyčejné TCP/IP spojení navázané klasicky z klienta na server.
-
Honza (neregistrovaný)
Právě Vy mluvíte o úplně nečem jiném a mícháte UDP s TCP. Sockety jedou na UDP a ne po TCP jako HTTP a jsou to naprosto jiné protokoly zcela jinak charakteristické. Naopak právě spojení HTTP a jeho establish trvá déle, protože se jedné u zaručený protokol nad TCP, oproti UDP, kde se Vám mohou ztratit data. Což vede k tomu, že HTTP nekomunikuje binárně a je mnohem "ukecanější", proto se použí UDP na např. video, ale je s tím problém na FW, protože často je tahle služba řezaná. Každopádně ani jedno není podstatné, protože to nic nemění na tom, co jsem psal a kdy Gugl narušuje bezpečnost uživatelů, protože v jeho návrhu Push API se z klienta stává fakticky server. To, že nyní mají dočasně socket spojení v Chrome není podstatné, protože oni navrhují model, co jsem psal a co je zásadně špatně.
-
Já jsem o UDP nenapsal ani čárku. To je hned první nepravdivá věta. "Sockety jedou na UDP" - socketem se označuje obecně komunikace mezi dvěma procesy, může to být internetová komunikace protokoly UDP, TCP nebo třeba přímo nad IP. Může to být třeba také unixový socket, kdy ta komunikace vůbec nejde přes síť, komunikují spolu dva procesy na jednom počítači. "Což vede k tomu, že HTTP nekomunikuje binárně" - za prvé to s přenosovým protokolem vůbec nesouvisí, přes TCP, UDP i cokoli jiného můžete komunikovat jak textově, tak binárně. Za druhé protokolem HTTP se běžně přenášejí binární data, i textové soubory se často přenášejí binárně - zkomprimované. Protokol HTTP/2 už je binární sám o sobě, tj. nemá textové hlavičky ale binární. "v jeho návrhu Push API se z klienta stává fakticky server" - nestává. Klient naváže TCP/IP spojení na server GCM, což je ze síťového hlediska úplně to samé, jako když naváže spojení na HTTP server. "To, že nyní mají dočasně socket spojení v Chrome není podstatné, protože oni navrhují model, co jsem psal a co je zásadně špatně." Nevím, o jakém návrhu píšete (i když to tuším - pravděpodobně jste si něco vymyslel, jako ve zbytku komentáře), já píšu o tom, jak fungují dnes notifikace založené na GCM na Androidu a v Chrome.
-
Honza (neregistrovaný)
Tohle jsem přesně čekal, ale naprosto :-) Že já jsem nenapsal, že fakt http přenáší binární data a že opravdu je jasné, že když stahuji apps nebo zip fajl, že fakt to není base64. Jen mi přijde, že tahle diskuze nemá smysl, protože buď se budeme chytat za slovo a vysvětlovat si věci, které přeci dneska snad ví i dítě na ZŠ a nebo se budeme bavit o principu. Jinak nic jsem si nevymyslel a Vaše neustálé předjímání je od začátku diskuze, kdy buď budete chytat za slovo a nebo předjímat. Jde o QUIC protokol, který GG představil viz.https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html a je rozšířením SPDY protokolu a GG odpovídal při jeho intro, že chce prosadit změnu v TCP/IP tak, aby mohlo dojít k modelu, o kterém tady celou dobu píšu. GG sám zmínil, že tohle nemůže prosadit, protože to je nutné provést změnu do TCP stacku a MS na to reagoval, že se zatím nepřipojí. Proto GG uvedl extension, o které píšete a které já jen onen socket alá Android. Ale to právě Vy píšete o úplně něčem jiném než já!
-
Takže jsem to trefil správně. Popletl jste push notifikace a QUIC, které spolu vůbec nesouvisí, zamíchal jste to k nepoznání, a o takhle vzniklém guláši píšete. Drtivá většina dětí na ZŠ o těchhle technologiích neví vůbec nic, neví o nich ani většina dospělých a není to žádná hanba. Ale když o tom nevíte nic ani vy, tak o tom nepište příspěvky do diskuse s dalekosáhlými odsuzujícími závěry. Zvlášť když vás někdo upozorní, že jste to dost popletl.
Mimochodem, když už jste QUIC zmínil, QUIC je v současné době postaveno nad UDP, dávat ho nad TCP by byl nesmysl, protože by se přišlo o nejdůležitější důvod, proč QUIC vznikl, a to obejít se bez ustavení TCP/IP spojení, které trvá dlouho. Google by mohl chtít udělat z QUIC samostatný protokol na stejné úrovni jako TCP, UDP, ICMP nebo SCTP, ale nevidím k tomu důvod. S nějakými otevřenými porty na klientovi to nesouvisí, komunikace QUIC protokolem se navazuje úplně stejně, jako v TCP/IP nebo UDP, tedy ze strany klienta. S push notifikacemi a GCM to má jedinou souvislost - autorem je Google a je to implementované v Chrome. Jinak to spolu vůbec nijak nesouvisí. -
Honza (neregistrovaný)
Ale já o tom píšu od začátku a to, co píšete jsem psal několikrát a za to, že jste to popletl Vy a nechopil za to já nemůžu. Pořád po mě opakujete, co jsem psal já jako první i ad režie TCP spojení a právě zmínky ad rychlost UDP. Kromě toho toho právě popisoval GG, že chce prosadit při push notifikacích. Promiňte, ale Vy sám nepochopíte pointu, pak opíšete po mě, co jsem psal sám za argumenty a pak to otočíte. To je k ničemu. Celou dobu hovořím o vlastním proprietárním protokolu GG, opakovaně mluvím o tom, že chce zasáhnout do OS a do TCP stacku a Vy najednou nakonec tvrdíte to, co já píšu. Dokonce na to v rámci IETF oslovil i zástupce Microsoftu, jak už jsme uvedl. Nechcete to taky po mě zopakovat?
-
Vůbec nejde o to, že jsem to napsal já. Jde o to, že za prvé tyhle dvě technologie řeší každá něco úplně jiného a jedna druhou vůbec nijak nepotřebují ani si navzájem nijak nepomohou, za druhé většina toho, co jste zde napsal, jsou nesmysly, tak nedí důvod myslet si, že zrovna tohle jste trefil správně, a za třetí na to nedokážete dát jediný odkaz. Kdyby to byla jenom jedna z těch tří věcí, ani bych o tom nedutal a šel bych se dovzdělat. Ale ta trojkombinace je mimořádně přesvědčivá.
-
Honza (neregistrovaný)
Poslední věc. Nedal jsem odkaz na tyhle dotazy ad QUIC a jejich plány. Teď to nevím a viděl jsem to někdy před cca 10-14 dny. Jo je to nesmysl já vím, jasně, je to spiknutí, vše je nesmysl, prosím zopakovat ještě 10x. A jak už jsem řekl, nato, jak tvrdíte, jak to jsou nesmysly, jak jste to po mě opakoval,ale vždy po mě, prakticky vše, ad HTTP, UDP atd atd. Ale to je fuk. Tohle zjevně nemá řešení, protože Vy prostě chcete chytat za slovo a druhého utlouct, že budete dokola tvrdit, že to jsou nesmysly. Dobře, tak ať se Vám to daří, tohle není a nebyl můj cíl a trávit čas internetovou diskuzí dokola vysvětlovat chytání za slovo je ztráta času a přetahovat se ad hominem argumenty, kdo tvrdí více nesmysl, hlavně když jsme v kruhu a opisujete to, co jsem psal já. Zdravím.
-
Honza (neregistrovaný)
A nemám na to link, takže můžete zase tvrdit, jak to není pravda a nebo něco po mě zopakovat. Ale právě u Notifikací právě lidé z Chrome vývoje odkazovali na FF a jejich model, protože na to padnul dotaz. Právě vyjádření, že je to dobrý nápad, ale že musí být řešen systémové a jako protokol a to v souvislosti s uvedením QUIC. Jo link teď nemám, takže jasně, oni o FF neví, nic neregistrují, nikdo se jich neptá a vše je spiknutí proti nesouhlasu s jejich prosazením toho protokolu a já jsem vůdce Kim :-)
-
Honza (neregistrovaný)
A právě to, co GG diskutuje kolem návrhu QUIC, tak tohle udělal FF v Notification API, kde je ten agent tunelují OS.A proto jsem o ní v úvodu psal, protože GG toho chce dosáhnout, ale systémovou změnou a ne jako FF a má tenhle návrh, který zátím je poměrně při zemi, ale v odpovědích zmínil, že chce, aby byl v OS. Ten link na to nemám a najděte si to sám, nevím, jestli to bylo u toho blogu na Chromiu nebo na YT Chromu, je unávné diskutovat s někým, kdo chytá za slovo a ani sám nemá aktuální info.
-
Push v HTTP/2 je úplně něco jiného, než push notifikace. Je to přenos souboru, který zahájí server místo klienta (jak je v HTTP obvyklé). Používá se např. proto, aby server s HTML stránkou rovnou poslal soubor se styly, a nečekalo se na to, až prohlížeč stránku rozparsuje a o soubor sám požádá. Dalo by se to použít i pro ty notifikace, ale ty jdou udělat i s HTTP/1.1. U notifikací je ale pořád důležité ještě to, že je to dlouhotrvající spojení (řádově delší, než běžné HTTP spojení), a že se připojuje pouze k jednomu serveru, který ty notifikace rozesílá.
-
Protože přenos malého souboru se dělá v rámci spojení, které trvá pár sekund nebo hodin, notifikace v rámci spojení, které trvá hodiny. Navíc posílat ping přes HTTP by nebylo moc efektivní. Jinak notifikace se samozřejmě používaly už s protokolem HTTP/1.1, ale nebylo to efektivní – proto přišel standard WebSocket a proto teď Google přichází s notifikacemi, které nejsou vázané na právě otevřenou stránku.
-
Honza (neregistrovaný)
A ještě se podívejte, co je to to, co označujete za "dlouhotrvající spojení" a jak vlastně fungují sockety. Je to úplně stejný princip, co dneska mají JS huby, pořád se posílá několik málo packetů aby nedošlou k vytimeoutování klienta. Problém je, že jedete u socketů po UDP a to většina FW vám uřízne. Proto také P2P klienti jednou pro established spojení na HTTP, aby protunelovali FW, pokud např. jsou za NATem a pochopitelně pak jsou pomalé, jinak je tam UDP komunikace jako plně binální forma a ne nějaké XML vata jako definuje HTTP. Ale u JS hubu je Vám to úplně jedno. Neboli pořád mluvím o tomtéž a pořád bude v rámci TCP/IP možné řešení na Push technologii, pokud nebude established request od klienta/prohlížeče jako prvního, aby služby protunelovala lokální FW: Proto také Gugl mluvil o tom, že jeho změna by mohla zasáhnout do OS, protože se týká TCP stacku, protože chce plně kontrolovat ten tok. Je to hrozně triviální, jen ty marketingové názvy jako Notification API, Push API atd. jsou pro lidi neznalé sítí. A pořád píšu o tomtéž, protože prostě na tom není možné co jiného vymyslet, pokud si gugl neprosadí úplně nový proprietární protokol vedle TCP/IP.
-
Pořád píšete o tomtéž, ale pořád i něčem jiném, než jsou push notifikace přes GCM implementované v Chrome. Tam nejsou žádné zásahy do TCP stacku OS (jak by to Google asi dokázal), žádné UDP, nic takového. Je to obyčejné TCP/IP spojení navázané z klienta (Chrome, Google Play) na server GCM, typicky na port 5228. Pokud máte spuštěný aktuální Chrome, vypište si
netstat -ntp | grep 5228, tam to spojení uvidíte. -
Honza (neregistrovaný)
Říkám si, jestli je to chyba internetové diskuze, nebo to blbě píšu nebo Vy blbě chápete. Já jsem jako první psal, že Android komunikuje po socketu na GCM. O Zásahu do OS mluvil Google v souvislosti s návrhem do OS, který by musel udělat, proto nyní mají socket komunikaci na Chrome. Ale navrhují zásah do OS a změnu protokolu tak, aby byl standardizován request ze serveru na klienta a prošel. Co je na tom k nepochopení? To, že nyní to nemohou implementovat, protože MS drží 98% destopů a Chrome musí splnit standardní chování TCP/IP protokolu? Takže musí jet přes socket, i když se snaží do stacku prosadit svůj proprietární Push protokol? Nevím, jak Vám to jinak napsat, abyste to pochopil. To, že se teď nějak chová je dáno status quo, ale Gugl chce víc a chce povolit requesty ze serveru? Co na tom nechápete?
-
Vy jste sice jako první psal o GCM, jenže jste napsal "To vetsina desktopovych fw zastavi a odstreli, ale Chrome si nastavi vyjimku a protuneluje fw". Což je nesmysl. Za prvé desktopové firewally mají už od výrobce předdefinovaná pravidla, co propouštějí, jinak by uživatele otravovaly i při navázání HTTP spojení na port 80. Za druhé i pokud takové pravidlo firewall nemá, při pokusu o navázání komunikace se firewall uživatele dotáže. Ale hlavně, firewall, který by umožnil aplikaci, aby si sama nastavila výjimku, by byl úplně k ničemu. O zásahu do OS tady píšete pořád jenom vy. Navázání komunikace ze serveru na klienta je možné, nic tomu nebrání, protokol TCP/IP to nijak nerozlišuje a OS tomu nijak nebrání. Ony totiž i ty servery běží na nějakém OS, a navázat s nimi komunikaci se překvapivě daří i bez zásahu do operačního systému. Pokud by Google implementoval jinou komunikaci, než přes TCP/IP, pořád to bude socket, protože socket je obecné označení pro socketovou komunikaci. O tom, že se Google pokouší do stacku prosadit svůj proprietární push protokol, píšete jenom vy, a na 99,9 % je to blábol. Možná si to pletete s QUIC protokolem, na který ale stejně nesedí většina toho, co píšete.
Větu, že chce Google povolit požadavky ze serveru, chápu. Akorát nechápu, proč něco takového píšete, když je to zjevný nesmysl - za prvé by to Googlu pro notifikace k ničemu nebylo, a za druhé požadavky ze serveru povolené jsou od okamžiku vzniku protokolu IP. Používá se to třeba v klasickém FTP, kdy klient naváže se serverem řídící spojení, ale pro přenos dat je pak spojení navazováno ze serveru ke klientovi (proto se pak začalo používat pasivní FTP, protože tohle navázání spojení neprošlo přes síťový firewall nebo NAT - ale OS na koncové stanici tomu opravdu nebránil). -
Honza (neregistrovaný)
Nesmysl to není a pořád mícháte hrušky s jabkama. Jen krátce, protože Vy umlátíte druhého opakovaným tvrzením nesmyslů a opakujete věci, co jsem napsal jako první já a pak Vy je jen opakujete. HTTP/80 vůbec nijak nesouvisí s GCM, protože to jede na portu 5235, žádný 80 a to jsem psal.
-
Nikde jsem nepsal, že spolu HTTP a GCM nějak souvisí, pouze jsem uváděl že spojení pro GCM je ze síťového hlediska úplně stejné, jako HTTP spojení. Jinak HTTP server klidně může běžet i na portu 5235, vůbec nic tomu nebrání. A primární port pro GCM je 5228, jak jsem psal v komentáři výše, používají se také porty 5229 a 5230. Port 5235 se pro GCM nepoužívá.
Tím, kdo míchá hrušky s jablkama, jste v této diskusi vy. Pokud máte pocit, že je to opačně, tak si mé komentáře přečtěte ještě jednou, pomalu a pořádně, a dohledávejte si věci, které tam píšu. Až přestanete mít pocit, že tam píšu něco špatně, tak jste ty komentáře konečně správně pochopil a dozvěděl jste se něco málo o síťových protokolech. Ne že by to tak bylo pokaždé, když něco píšu, ale v tomto případě jsem si dost jistý. -
Honza (neregistrovaný)
No vidíte, to jsem Vám jen chtěl ukázat, jaké je to chytání za slovo, které tady celou dobu děláte ad Váše banální přednáška o bináru po HTTP a ještě si vyguglete další porty, na kterých jede GCM a udělejte další přednášku o banalitách. No četl jsem Vás pozorně, ale vždy opisujete, co jsem já již dávno napsal a pak to rozvedete viz ted ty porty (jo jasně, umíte používat GG). Ale to není ta pointa, šlo o chávní FW a jeho řezení komunikace apochopitelně každý horní port neprojde. Prostě tomu nerozumíte, ale už je to jedno, občanky si trhat nebudeme ;-) Jdu raději ven, tohle nemá cenu. Mějte se.
-
Honza (neregistrovaný)
A ještě doplním. Dneska existuje mnoho různých Javascript hubu, které umí notifikace řešit a fungují na základě vyžádaných requestů z klienta, takže FW může zapojit jak blbou politiku pro established spojení, tak pokročilé mohou sledovat i heuristickou analýzu pro timestamps apod. Ale nevyžádané requesty na klienta to je přímo rajská hudba pro hacky a můžeme se tady pak jen předhánět v nápadech, jak klienty dostat a jak na ně následně útočit (a to píšu i s vědomím, že gugl bude tohle obhajovat, že je to approval technologie a že bude per IP vázaná apod. - btw co asi uživatelé budou approvat jako první a co je nejnavštěvovanější na netu? porno a sex a ideální pro útoky). Kromě toho mi vadí, jak gugl si vymýšlí, že to něco ušetří. Puste si Wireshark nebo jakýkoliv netmonitor a uvidíte, kolik bajtíků posílají ty JS huby a v dnešních linkách je to šměšné. Dokonce i na GPRS tyhle huby valí jak z praku. Takže v tom důvod není, ale jen to, že gugl neví, jak si ještě zvíšit revenue a hledá cesty kde to jde a tohle je ideální metoda, jak userům nakonec rvát reklamy - jo jasně, v úvodu bude vše úža a nic jiného než data asi jako YT, ale pak řeknou, že to přeci nejde jen ta provozovat, že provoz něco stojí a sorry userové, ale musíme vám navalit reklamu. A to je dlouhodobý cíl maskovaný do těchto keců a hlavně se obětuje bezpečnost uživatelů na úkor snahu guglu do nekonečna zvyšovat revenue.
-
fd (neregistrovaný)
Googlu jde o to, aby usetrili oni, a pak predevsim o to, aby dostali z uzivatelu jeste vic osobnich dat a udaju. Mit pristup k jejich zarizenim 24/7 bez ohledu na aktivitu uzivatele je jejich sen. Aktualne jim v tom brani firewally a NATy.
Jeste zareaguji na UDP ... UDP se pouziva prakticky a vyhradne tam, kde vypadek nejakeho paketu nehraje roli (hry, audio, video). V pripade (nejen)webu je to naprosto nepouzitelne. Respektive to dopadne tak, ze se nad UDP bude realizovat to, co TCP stack realizuje v systemu - tedy zajisteni garance prenosu.
Bonusem drtiva vetsina sitovych prvku prave UDP zacne zahazovat jako prvni, pokud dojde na nejaky problem se zatizenim.
Uzivateli UDP ani v idealnim pripade nemuze nic prinest, protoze specielne v pripade webu zdaleka nejdele trva reneder stranky, latence tpc je v tomto ohledu v radu promile.
-
toTem (neregistrovaný)
Moc lepsich zpusobu jak identifikovat jednotlivce/uzivatele nez persistentni a temer? nesmazatelne scriptionId bych nevymyslel. Ted pro to hakuji headery a heuristikama celkem dobre tipuji, ted to dostanou zadarmo. Dalsi reklamni kanal se hodi... dont be evil, ale pro jistotu zacneme psat opensource adblock i pro filtrovani obsahu v techto push-connections.