{"id":295,"date":"2020-04-05T23:37:15","date_gmt":"2020-04-05T21:37:15","guid":{"rendered":"http:\/\/tech.sosthe.sk\/?p=295"},"modified":"2020-04-06T16:49:39","modified_gmt":"2020-04-06T14:49:39","slug":"2-8-p2p-siete","status":"publish","type":"post","link":"http:\/\/tech.sosthe.sk\/index.php\/2020\/04\/05\/2-8-p2p-siete\/","title":{"rendered":"2.8. P2P siete"},"content":{"rendered":"<p>Peer-to-peer (P2P, alebo po slovensky rovn\u00fd s rovn\u00fdm) je architekt\u00fara, ktor\u00e1 sa v s\u00fa\u010dasnosti najmas\u00edvnej\u0161ie pou\u017e\u00edva na zdie\u013eanie a paraleln\u00e9 kop\u00edrovanie s\u00faborov (\u010dasto s obsahom poru\u0161uj\u00facim autorsk\u00e9 pr\u00e1va tvorcov). P2P architekt\u00fara sa v\u0161ak pou\u017e\u00edva napr\u00edklad aj na telefonovanie na internete alebo na distribuovan\u00e9 v\u00fdpo\u010dty. Hlavnou v\u00fdhodou P2P siet\u00ed je \u0161k\u00e1lovate\u013enos\u0165 prostriedkov. V pr\u00edpade klient\/server architekt\u00fary je \u010dastou podmienkou v\u00fdkonn\u00fd server, alebo klaster serverov, na ktor\u00e9 spad\u00e1 hlavn\u00e1 z\u00e1\u0165a\u017e, aby poskytli slu\u017eby mnoh\u00fdm klientom s\u00fa\u010dasne. Pri P2P architekt\u00fare sa z\u00e1\u0165a\u017e rozklad\u00e1 na pripojen\u00fdch peerov, z ktor\u00fdch \u017eiaden nemus\u00ed by\u0165 v\u00fdnimo\u010dne v\u00fdkonn\u00fd. Ak ide o hybrid klient\/server a P2P architekt\u00fary, tak server je \u010dasto ch\u00e1pan\u00fd iba ako miesto, kde je umiestnen\u00fd \u201ecentr\u00e1lny register\u201c peerov a hlavn\u00fa z\u00e1\u0165a\u017e (napr. posielanie s\u00faborov) u\u017e preberaj\u00fa na seba samotn\u00ed peerovia.<\/p>\n<h3>2.8.1\u2002 Porovnanie klient\/server architekt\u00fary a P2P architekt\u00fary pri distrib\u00facii s\u00faboru.<\/h3>\n<p>\u0160k\u00e1lovate\u013enos\u0165 P2P siet\u00ed sa d\u00e1 \u013eahko uk\u00e1za\u0165 pri probl\u00e9me distribuovania s\u00faboru z jedn\u00e9ho na N po\u010d\u00edta\u010dov. Predpokladajme nasleduj\u00facu situ\u00e1ciu zobrazen\u00fa na obr\u00e1zku.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-296 size-full aligncenter\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig02_24.gif\" alt=\"\" width=\"575\" height=\"489\" \/><\/p>\n<p>Ka\u017ed\u00fd z po\u010d\u00edta\u010dov je napojen\u00fd do internetu, o ktorom v tomto modeli predpoklad\u00e1me, \u017ee m\u00e1 dostato\u010dn\u00fa prenosov\u00fa r\u00fdchlos\u0165, aby nespoma\u013eoval \u017eiadnu potrebn\u00fa komunik\u00e1ciu. Na\u0161ou \u00falohou je distribuova\u0165 s\u00fabor zo servera na N po\u010d\u00edta\u010dov. Prenosov\u00e1 r\u00fdchlos\u0165 servera pre upload nech je u<sub>s<\/sub>\u00a0a pre cie\u013eov\u00e9 po\u010d\u00edta\u010de u<sub>1<\/sub>\u00a0a\u017e u<sub>N<\/sub>. Pri serveri n\u00e1s \u0161\u00edrka p\u00e1sma pre download nezauj\u00edma. Cie\u013eov\u00e9 po\u010d\u00edta\u010de maj\u00fa \u0161\u00edrku p\u00e1sma pre download d<sub>1<\/sub>\u00a0a\u017e d<sub>N<\/sub>.<\/p>\n<p>Pri klient\/server architekt\u00fare mus\u00edme posiela\u0165 cel\u00fd s\u00fabor zo servera ka\u017ed\u00e9mu klientovi zvl\u00e1\u0161\u0165. R\u00fdchlos\u0165 je ovplyvnen\u00e1 hodnotami u<sub>s<\/sub>\u00a0a d<sub>1<\/sub>\u00a0a\u017e d<sub>N<\/sub>. Doln\u00fd odhad celkov\u00e9ho \u010dasu potrebn\u00e9ho na distrib\u00faciu s\u00faboru ve\u013ekosti F je max{NF\/u<sub>s<\/sub>, F\/min{d<sub>1<\/sub>,\u2026 , d<sub>N<\/sub>}}. Pri ve\u013ekom N rastie tento \u010das line\u00e1rne s hodnotou N.<\/p>\n<p>V P2P architekt\u00fare sta\u010d\u00ed, aby server poslal v\u0161etk\u00fdm peerom dohromady jednotliv\u00e9 \u010dasti s\u00faboru, ktor\u00fd m\u00e1 ve\u013ekos\u0165 F aspo\u0148 raz, na \u010do mu sta\u010d\u00ed \u010das minim\u00e1lne F\/u<sub>s<\/sub>. Peerovia si u\u017e vedia jednotliv\u00e9 \u010dasti poposiela\u0165 medzi sebou, t.j. ka\u017ed\u00fd sa stane poskytovate\u013eom t\u00fdch d\u00e1t, ktor\u00e9 u\u017e m\u00e1 k dispoz\u00edcii. Ka\u017ed\u00fd z peerov si teda mus\u00ed stiahnu\u0165 cel\u00fd s\u00fabor raz, na \u010do potrebuje \u010das F\/d<sub>i<\/sub>. Celkov\u00e1 \u0161\u00edrka p\u00e1sma na upload s\u00faboru nar\u00e1stla a\u017e na u<sub>s<\/sub>+u<sub>1<\/sub>+\u2026+u<sub>N<\/sub>. Celkovo je potrebn\u00e9 cez tento upload posla\u0165 klientom NF d\u00e1t. Doln\u00fd odhad celkov\u00e9ho \u010dasu potrebn\u00e9ho na distrib\u00faciu s\u00faboru ve\u013ekosti F je max{F\/u<sub>s<\/sub>, F\/min{d<sub>1<\/sub>,\u2026 , d<sub>N<\/sub>},NF\/(u<sub>s<\/sub>+u<sub>1<\/sub>+\u2026+u<sub>N<\/sub>)}.<\/p>\n<h3>2.8.2\u2002 P2P s centr\u00e1lnym adres\u00e1rom (Napster)<\/h3>\n<p>Z\u00e1kladn\u00fdm probl\u00e9mom rie\u0161en\u00fdm v P2P sie\u0165ach je n\u00e1js\u0165 peerov, ktor\u00ed s\u00fa schopn\u00ed poskytn\u00fa\u0165 h\u013eadan\u00e9 d\u00e1ta. Prvou P2P sie\u0165ou poskytuj\u00facou vo\u013en\u00e9 s\u0165ahovanie mp3 s\u00faborov bol Napster uveden\u00fd do prev\u00e1dzky v roku 1999. V skuto\u010dnosti ide o hybrid P2P a klient-server architekt\u00fary. Jadro architekt\u00fary Napsteru predstavoval centr\u00e1lny server, ktor\u00fd centr\u00e1lne indexoval obsahy adres\u00e1rov pripojen\u00fdch peerov. Vyh\u013ead\u00e1vanie \u017eiadan\u00e9ho s\u00faboru sa vykonalo nad t\u00fdmto indexom a h\u013eadaj\u00facim peerom boli zasielan\u00e9 zoznamy peerov, ktor\u00ed zdie\u013eaj\u00fa h\u013eadan\u00fd obsah. Samotn\u00e9 kop\u00edrovanie s\u00faborov sa u\u017e realizovalo mimo hlavn\u00fd server. T\u00e1to architekt\u00fara nebola odoln\u00e1 vo\u010di pr\u00e1vnick\u00fdm \u00fatokom nahr\u00e1vac\u00edch spolo\u010dnost\u00ed a server musel by\u0165 odpojen\u00fd od siete. Tento krok si \u201evyn\u00fatil\u201c vznik distribuovan\u00fdch sp\u00f4sobov vyh\u013ead\u00e1vania, v ktor\u00fdch po odpojen\u00ed \u013eubovo\u013en\u00fdch po\u010d\u00edta\u010dov sie\u0165 neprestane fungova\u0165.<\/p>\n<h3>2.8.3\u2002 \u010cist\u00e1 P2P sie\u0165 (Gnutella)<\/h3>\n<p>Opa\u010dn\u00fdm extr\u00e9mom vo\u010di centr\u00e1lnemu indexovaciemu serveru je \u010dist\u00e1 P2P sie\u0165 bez ak\u00e9hoko\u013evek servera, kde s\u00fa si v\u0161etci peerovia rovn\u00ed a maj\u00fa v sieti rovnak\u00e9 pr\u00e1va a povinnosti. Pr\u00edkladom takejto siete je p\u00f4vodn\u00fd n\u00e1vrh siete Gnutella. Pri takejto architekt\u00fare vznikaj\u00fa dva nov\u00e9 probl\u00e9my. Prv\u00fdm je ot\u00e1zka, ako sa do siete napoji\u0165, ke\u010f neexistuje centr\u00e1lny prihlasovac\u00ed server. Druh\u00fdm je sp\u00f4sob vyh\u013ead\u00e1vania v takejto sieti.<\/p>\n<p>Na to, aby sa pr\u00e1ve spusten\u00fd P2P program dok\u00e1zal napoji\u0165 do siete, potrebuje pozna\u0165 aspo\u0148 jedn\u00e9ho peera, ktor\u00fd sa u\u017e v sieti nach\u00e1dza. Je to rie\u0161en\u00e9 tak, \u017ee ka\u017ed\u00fd klient m\u00e1 nejak\u00fd zoznam peerov, o ktor\u00fdch vie, \u017ee v sieti u\u017e boli\/s\u00fa napojen\u00ed. Ke\u010f\u017ee peerovia sa m\u00f4\u017eu kedyko\u013evek prip\u00e1ja\u0165 a odp\u00e1ja\u0165, nemus\u00ed s pokusom o napojenie na nich uspie\u0165. \u00davodn\u00fd zoznam pre Gnutellu sa d\u00e1 z\u00edska\u0165 od niektor\u00e9ho nad\u0161en\u00e9ho \u010dlena siete, ktor\u00fd prev\u00e1dzkuje GWC (Gnutella Web Cache) a pochv\u00e1li sa o tom na IRC. GWC je napojen\u00fd do siete ako peer a neust\u00e1le aktualizuje zoznam IP adries peerov, ktor\u00fdch \u201evid\u00ed\u201c pripojen\u00fdch. Niektor\u00e9 adresy GWC poskytovate\u013eov b\u00fdvaj\u00fa tie\u017e s\u00fa\u010das\u0165ou in\u0161tal\u00e1ci\u00ed klientov.<\/p>\n<p>Vyh\u013ead\u00e1vanie a vytv\u00e1ranie nov\u00fdch napojen\u00ed v takejto \u010distej P2P sieti je realizovan\u00e9 takzvan\u00fdm \u201eQuery flooding\u201c algoritmom, teda zaplavovan\u00edm ot\u00e1zkou. Po tom, ako sa klient napoj\u00ed na niektor\u00e9ho \u010dlena siete, chce vytvori\u0165 \u010fal\u0161ie spojenia, aby jeho kontakt so sie\u0165ou bol \u201epevnej\u0161\u00ed\u201c. Po\u0161le tomu peerovi, na ktor\u00e9ho sa mu podarilo napoji\u0165, spr\u00e1vu naz\u00fdvan\u00fa\u00a0<em>Ping<\/em>, ktor\u00e1 m\u00e1 v sebe po\u010d\u00edtadlo preposlan\u00ed. Kedyko\u013evek niektor\u00fd z peerov dostane spr\u00e1vu\u00a0<em>Ping<\/em>, zn\u00ed\u017ei po\u010d\u00edtadlo preposlan\u00ed o 1 a prepo\u0161le t\u00fato\u00a0<em>Ping<\/em>\u00a0spr\u00e1vu v\u0161etk\u00fdm svojim susediacim peerom, s ktor\u00fdmi m\u00e1 vytvoren\u00e9 spojenie. Ak ku peerovi doraz\u00ed spr\u00e1va\u00a0<em>Ping<\/em>\u00a0s po\u010dtom preposlan\u00ed nula, posiela spr\u00e1vu\u00a0<em>Pong<\/em>\u00a0peerovi, ktor\u00fd t\u00fato spr\u00e1vu inicioval. Ten si potom vyberie z mno\u017estva\u00a0<em>Pong<\/em>\u00a0odpoved\u00ed niektor\u00fdch peerov, s ktor\u00fdmi vytvor\u00ed nov\u00e9 spojenie. Po tejto inicializa\u010dnej f\u00e1ze m\u00f4\u017ee podobn\u00fdm sp\u00f4sobom vyh\u013ead\u00e1va\u0165. Po\u0161le v\u0161etk\u00fdm svojim susedom ot\u00e1zku. T\u00edto peerovia ot\u00e1zku preposielaj\u00fa \u010falej. Ak niektor\u00fd z peerov zist\u00ed, \u017ee m\u00e1 obsah, ktor\u00fd bol v ot\u00e1zke vyh\u013ead\u00e1van\u00fd, odpovie priamo h\u013eadaj\u00facemu a kop\u00edrovanie sa m\u00f4\u017ee realizova\u0165.<\/p>\n<p>V s\u00fa\u010dasnosti u\u017e Gnutella nem\u00e1 tak\u00fato P2P architekt\u00faru, kde s\u00fa si v\u0161etci peerovia rovn\u00ed, ale vytv\u00e1ra\u00a0<strong>hierarchick\u00fa sie\u0165<\/strong>, kde sa peerovia delia na be\u017en\u00fdch peerov a super peerov, na ktor\u00fdch s\u00fa be\u017en\u00ed peerovia napojen\u00ed. Super peerovia si vytv\u00e1raj\u00fa mal\u00fd index zdie\u013ean\u00fdch s\u00faborov na nich napojen\u00fdch be\u017en\u00fdch peerov a samotn\u00fd algoritmus Query flooding sa realizuje u\u017e iba medzi super peermi. To, ktor\u00fd peer sa stane super peerom, sa m\u00f4\u017ee priebe\u017ene meni\u0165 pod\u013ea situ\u00e1cie v sieti, preto\u017ee aj super peerovia sa m\u00f4\u017eu pokojne odp\u00e1ja\u0165 od siete. Be\u017en\u00ed peerovia s\u00fa preto \u010dasto napojen\u00ed na viacer\u00fdch super peerov, aby sa nestalo, \u017ee sa odpojen\u00edm jedn\u00e9ho super peera odpoja aj oni. Naj\u010dastej\u0161ie sa super peerom st\u00e1vaj\u00fa po\u010d\u00edta\u010de s r\u00fdchlym pripojen\u00edm a samozrejme verejnou IP adresou.<\/p>\n<p>Medzi hierarchick\u00e9 P2P siete patr\u00ed napr. aj Kazaa s jej protokolom FastTrack.<\/p>\n<h3>2.8.4\u2002 BitTorrent<\/h3>\n<p>BitTorrent je v s\u00fa\u010dasnosti najpopul\u00e1rnej\u0161\u00ed P2P protokol. Ide o hybrid klient\/server a peer-to-peer architekt\u00fary. Jeho \u0161pecifikom je to, \u017ee skupinu komunikuj\u00facich peerov, tzv. torrent, sp\u00e1ja konkr\u00e9tny s\u00fabor alebo adres\u00e1r, ktor\u00fd poskytuj\u00fa a s\u0165ahuj\u00fa. Serverom ka\u017ed\u00e9ho torrentu je takzvan\u00fd tracker, ktor\u00fd registruje IP adresy z\u00fa\u010dastnen\u00fdch peerov. Zistenie toho, kto je pre dan\u00fd s\u00fabor trackerom, sa realizuje cez vyh\u013ead\u00e1vacie webov\u00e9 str\u00e1nky. Webov\u00e9 str\u00e1nky, ktor\u00e9 poskytuj\u00fa vyh\u013ead\u00e1vanie trackerov s obsahom poru\u0161uj\u00facim autorsk\u00e9 pr\u00e1va, s\u00eddlia v\u00e4\u010d\u0161inou v krajin\u00e1ch so slab\u00fdmi z\u00e1konmi vo\u010di po\u010d\u00edta\u010dovej kriminalite. Zoznamy trackerov pre dan\u00fd s\u00fabor sa poskytuj\u00fa v s\u00faboroch s pr\u00edponou .torrent.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-297 size-full\" src=\"http:\/\/tech.sosthe.sk\/wp-content\/uploads\/2020\/04\/fig02_26.gif\" alt=\"\" width=\"651\" height=\"545\" \/><\/p>\n<p>Po napojen\u00ed na tracker sa peer dozvie nejak\u00fa podmno\u017einu peerov v danom torrente, od ktor\u00fdch m\u00f4\u017ee za\u010da\u0165 \u017eiada\u0165 zoznam dostupn\u00fdch \u010dast\u00ed s\u00faboru a poskytnutie niektorej z nich. S\u00fabory v sieti BitTorrent s\u00fa rozk\u00faskovan\u00e9 na mal\u00e9 \u010dasti (256 KB alebo in\u00e9 mocniny dvojky) naz\u00fdvan\u00e9 chunks. Ka\u017ed\u00fd chunk je mo\u017en\u00e9 z\u00edska\u0165 od in\u00e9ho peera.<\/p>\n<p>Pri pou\u017eit\u00ed\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Distributed_hash_table\">DHT<\/a>\u00a0a\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Magnet_URI_scheme\">magnet odkazov<\/a>\u00a0tracker poskytuje len magnet link, ktor\u00fd ukazuje na torrent, ktor\u00fd si u\u017e klient stiahne od peerov zapojen\u00fdch v DHT.<\/p>\n<p>Na zn\u00ed\u017eenie z\u00e1\u0165a\u017ee trackerov sa, po napojen\u00ed do torrentu, daj\u00fa na z\u00edskavanie adries \u010fal\u0161\u00edch peerov pou\u017ei\u0165\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Peer_exchange\">Peer exchange<\/a>\u00a0(PeX) a LocalPeerDiscovery\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Local_Peer_Discovery\">LPD<\/a>. Pri PeX si od u\u017e pripojen\u00fdch peerov vy\u017eiada peerov, ktor\u00ed s\u00fa napojen\u00ed na neho. Pri LPD pomocou broadcastu peer objavuje nov\u00fdch peerov na lok\u00e1lnej sieti.<\/p>\n<p>Protokol siete BitTorent je navrhnut\u00fd tak, \u017ee akon\u00e1hle niektor\u00fd peer stiahne nejak\u00e9 \u010dasti s\u00faboru, st\u00e1va sa automaticky ich poskytovate\u013eom. Samozrejme, \u017ee niektor\u00ed klienti sa m\u00f4\u017eu rozhodn\u00fa\u0165 neposkytova\u0165 ni\u010d, t. j. \u201eby\u0165 v m\u00f3de download only\u201c. S\u00fa to takzvan\u00ed free-rideri. Sie\u0165 BitTorrent m\u00e1 v\u0161ak n\u00e1dhern\u00e9 regula\u010dn\u00e9 mechanizmy, ako zv\u00fdhodni\u0165 peerov, ktor\u00ed s\u00fa ochotn\u00ed poskytn\u00fa\u0165 svoje stiahnut\u00e9 \u010dasti s\u00faboru. Ka\u017ed\u00fd z peerov posiela svoje \u010dasti (odpoved\u00e1 na po\u017eiadavky na stiahnutie) iba 4 peerom s\u00fa\u010dasne. Uprednost\u0148uje t\u00fdch peerov, ktor\u00ed mu poskytli ich \u010dasti s najv\u00e4\u010d\u0161ou r\u00fdchlos\u0165ou prenosu. T\u00fdchto najlep\u0161\u00edch 4 peerov vyhodnocuje ka\u017ed\u00fdch 10 sek\u00fand. Okrem toho, ka\u017ed\u00fdch 30 sek\u00fand si vyberie jedn\u00e9ho n\u00e1hodn\u00e9ho \u017eiadate\u013ea a po\u0161le mu svoje \u010dasti. Tento nov\u00fd \u017eiadate\u013e sa m\u00f4\u017ee sta\u0165 jedn\u00fdm zo 4 najlep\u0161\u00edch. Tak\u00fdmto sp\u00f4sobom postupne spolu komunikuj\u00fa hlavne peerovia, ktor\u00ed s\u00fa \u201erovnako \u0161tedr\u00ed\u201c. V\u00fdber n\u00e1hodn\u00e9ho \u017eiadate\u013ea je potrebn\u00fd aj na to, aby sa v\u0161etci peerovia mohli dosta\u0165 minim\u00e1lne k svojim prv\u00fdm chunk-om.<\/p>\n<h3>2.8.5\u2002 Skype<\/h3>\n<p>Skype je pr\u00edkladom neverejn\u00e9ho (uzavret\u00e9ho) protokolu. To znamen\u00e1, \u017ee neexistuje RFC, ktor\u00e9 by ho popisovalo. V\u0161etko, \u010do o tomto \u00faspe\u0161nom P2P protokole vieme, je iba odpozorovan\u00e9 z jeho spr\u00e1vania alebo zisten\u00e9 reverzn\u00fdm in\u017einierstvom.<\/p>\n<p>Skype tvor\u00ed hierarchick\u00fa sie\u0165, v ktorej s\u00fa be\u017en\u00ed peerovia a super peerovia. Peer sa pri nap\u00e1jan\u00ed do siete prip\u00e1ja na centr\u00e1lny server, kde sa autentifikuje a n\u00e1sledne sa napoj\u00ed na niektor\u00e9ho zo super peerov. Jeho super peer zis\u0165uje od ostatn\u00fdch super peerov, \u010di s\u00fa jeho kontakty pripojen\u00e9 do siete. V \u010dase, ke\u010f chce peer realizova\u0165 hovor alebo chat, informuje o tom cie\u013eov\u00e9ho peera cez svojho a jeho super peera. Samotn\u00fd rozhovor u\u017e prebieha len medzi koncov\u00fdmi peermi. V\u00fdnimkou je, ak obaja peerovia maj\u00fa neverejn\u00fa IP adresu. Vtedy super peer ur\u010d\u00ed peera s verejnou IP adresou ako sprostredkovate\u013ea, na ktor\u00e9ho sa t\u00edto dvaja napoja a cel\u00fd rozhovor prebieha cez tieto spojenia. Sprostredkovate\u013e jednoducho preposiela pakety oboma smermi bez toho, aby o tom pou\u017e\u00edvate\u013e tohto sprostredkovate\u013ea vedel.<\/p>\n<p>Od roku 2012 m\u00e1 Skype v\u0161etk\u00fdch super-peerov hostovan\u00fdch na vlastn\u00fdch linuxov\u00fdch uzloch [<a href=\"http:\/\/arstechnica.com\/business\/2012\/05\/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft\/\">link<\/a>].<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Peer-to-peer (P2P, alebo po slovensky rovn\u00fd s rovn\u00fdm) je architekt\u00fara, ktor\u00e1 sa v s\u00fa\u010dasnosti najmas\u00edvnej\u0161ie pou\u017e\u00edva na zdie\u013eanie a paraleln\u00e9 kop\u00edrovanie s\u00faborov (\u010dasto s obsahom&hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[],"_links":{"self":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/295"}],"collection":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/comments?post=295"}],"version-history":[{"count":2,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/295\/revisions"}],"predecessor-version":[{"id":467,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/295\/revisions\/467"}],"wp:attachment":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/media?parent=295"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/categories?post=295"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/tags?post=295"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}