Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - pajon

Stran: [1] 2 3
1
Server / Re:PHP security - best practice?
« kdy: 11. 02. 2015, 16:27:17 »
Na urovni interpretera PHP sa da cez open_basedir. Inak spominana virtualizacia

2
Rok sa používa napríklad vtedy ak máš súbor, ktorý po aktualizácií bude mať inú adresu. Zväčša sa to robí tak, že máš adresu napríklad

http://example.com/assets/AABBCC/images/myimage.png

Reťazec AABBCC je náhodne vygenerovaný názov adresára, ktorý obsahuje aktuálne súbory. V prípade ak by sa súbor myimage.png zmenil, tak sa vytvorí nový adresár, ktorý bude mať iné meno ako ten predtým. Tým sa zmení aj cesta k súboru a súbor sa už nebude brať z cache.

3
Odkladiště / Re:Reset hesla na eBay
« kdy: 28. 05. 2014, 10:19:41 »
Ja som si práve dnes resetoval heslo a všetko prebehlo v poriadku.

4
V CV si uprav email. Počet najazdených km nikoho nezaujíma vzhľadom na to, že si hľadáš prácu v IT. Kraviny ako word, excel a podobne by som tiež nedával. Je to brané ako samozrejmosť.

5
Server / Re:Záloha web serveru?
« kdy: 27. 06. 2013, 17:09:54 »
Toto by mal riešiť samotný webhosting, avšak máloktorý hosting to poskytuje

6
Server / Re:Replikácia dát
« kdy: 18. 06. 2013, 22:43:36 »
Pri predpoklade že všetky snody o sebe vedia, určite nepotrebuješ aby všetky snody držali konzistentné kópie všetkých dát.
Rozmýšľal si rozdeliť možné hash hodnoty kľúčov medzi snody? Príklad: máš N (>= M) snodov a chceš držať aspoň M replík dát. To znamená že pre každú hash hodnotu budeš musieť vedieť určiť M snodov kde sa má hodnota nachádzať. A teraz máš nasledovné možnosti: [http://en.wikipedia.org/wiki/Quorum_(distributed_computing)]
a) chceš aby synchrónny zápis do takejto key value distribuovanej databázy prebehol čo najrýchlejšie. Zapisuješ naraz na všetkých M nodov, ale klientovi (v tomto prípade asi anodu) potvrdzuješ zápis už pri prvom úspešnom potvrdení od ktoréhokoľvek s-nodu.
b) chceš aby čítanie z DB prebehlo čo najrýchlejšie - Potvrdzuješ zápis až keď je zmena rozkopírovaná na všetky zodpovedné snody. Čítanie môžeš potom robiť z ktoréhokoľvek z nich.
c) chceš niečo medzi a a b - pri zápise čakáš na potvrdenie od n/2+1 uzlov.  Takisto realizuješ čítanie z n/2+1 uzlov.
Samozrejme pre hodnoty si musíš ukladať aj timestamp aby si vedel posúdiť ktorá verzia je najnovšia. Pri vymazaní hodnoty kľúč nemažeš, ale poznačíš si timestamp zmazania.

Samozrejme situácia je iná pokiaľ nepotrebuješ synchrónny zápis a je ti jedno že v niektorých okamihoch bude databáza nekonzistentná, a je pre teba dôležité iba aby niekedy doiterovala do konzistentného stavu.
Poprípade ak jednotlivé snody nevedia o všetkých s-nodoch a vymieňajú si informácie iba cez susedov. To by sa dalo riešiť najjednoduchšie tak že každý node po prijatí transakcie skontroluje či je pre neho nová ak áno tak si ju uloží a prepošle na všetkých ostatých susedov. Ak by bolo treba minimalizovať komunikáciu potom bude treba asi najprv treba skúsiť vytvoriť minimálny graf aby sa dáta neposielali duplicitne.

Ale to sú už iné story.

V prvom rade ďakujem za super odpoveď.

snody o sebe vedia a každý je s každým prepojený. Ak táto sieť bude reálne spustená tak počet snodov bude pár. Predpokladám max +-5

1. Na základe toho by sa dala aplikovať metóda, kedy pri vytvorený key-value bude potvrdená od všetkých snodoch.

2. Metóda, ktorá by sa dala použiť je práve práca s časom, kde sa hodnota uloží lokálne a rozpošle ostatným aktívnym snodom. V prípade ak by nastalo v rovnakom okamihu viac rovnakých autentifikácií na rozdielnych nodoch, bude platiť tá s menším časom a ostatné prepíše.

Pravdepodobne to spravím tým druhým spôsobom.

7
Server / Re:Replikácia dát
« kdy: 18. 06. 2013, 19:59:44 »
Je to verejné, ale myslel som, že toto bude stačiť. ( https://github.com/pajon/crycom )

Jedná sa o decentralizovaný komunikačný protokol realizovaný dvoma druhmi uzlov označovaný ako nodea snode, kde snode je superuzol. V princípe je to tak, že klienti sa pripájajú na nody a tie komunikujú s minimálne jedným snode. Vzhľadom na povahu protokolu, prebieha autentifikácia kde je potrebné overiť klienta. Po úspešnej autentifikácií sa vytvorí spomínaný key-value, ktorý sa rozpošle na ostatné snody. A tento záznam potrebujem udržať konzistentný na všetkých snodoch.

A používa sa to na to, že keď je klientA pripojený na node1 a klientB pripojený na node2 a chcú medzi sebou komunikovať aby vedel každý snode odpovedať kde sa aký klient nachádza.

Snáď to pochopíte.

8
Server / Re:Replikácia dát
« kdy: 18. 06. 2013, 19:36:03 »
Skúsim to trocha upresniť. Kľúč predstavuje identifikátor používateľa (32 - bajtový identifikátor) a hodnota je adresa uzla kde je používateľ pripojený (napríklad IPv4). Ak sa používateľ pripojí na daný uzol, vytvorí sa záznam (key-value už spomínané), ktorý upozorní, že sa daný používateľ pripojil na daný uzol.

9
Server / Replikácia dát
« kdy: 18. 06. 2013, 17:37:31 »
Dobrý deň.

Potýkam sa s problémom, keď mám viacero uzlov a každý generuje dáta (key-value), ktoré sa majú zdielať medzi uzlami. Je to v podstate master-master replikácia.

Chcel by som sa spýtať, či by ste mi nevedeli doporučiť nejaký konkrétny algoritmus, prípadne info ako by sa dalo s tým niečo spraviť.

Ďakujem

10
Vývoj / Re:Pomoc v c++
« kdy: 30. 05. 2013, 20:39:48 »
3 ukoncovacie zatvorky vtipne to neni

mám tam zátvorku na konci navyše, moja chyba. Ale ide o ten princíp

11
Vývoj / Pomoc s funkcí v C++
« kdy: 30. 05. 2013, 20:23:36 »
Dobrý deň,

chcel by som sa spýtať, aký je rozdiel v nasledujúcich kódoch, konkrétne tá funkcia.

Kód: [Vybrat]
class mojaTrieda {
public:
    void a() {
      b = 0;
    }

private:
    int b;
}
}

a

Kód: [Vybrat]
class mojaTrieda {
public:
    void a():
        b(0) {

    }


private:
    int b;
}
}

Je to totožné alebo to má nejaký iný význam tá druhá definícia ?

Ďakujem :)

12
Vývoj / Re:C++ soketové programování
« kdy: 13. 02. 2013, 10:49:30 »
skús sa pozrieť na libevent

13
Sítě / Re:Problémy s vysokými latencemi
« kdy: 11. 02. 2013, 17:35:32 »
Tým wifi, som nemyslel priamo wifi IEEE 802.11. Podľa webu používajú technológiu Next-G, prípadne nejaké technológie od Motoroly. Bližšie vám povedať nedokážem. Ono to fungovalo perfektne latencia (8-12ms) čo je lepšie než u niektorých provideroch po kábli, lenže sa to zvrtlo a už to ide čím ďalej tým horšie.

14
Sítě / Re:Problémy s vysokými latencemi
« kdy: 11. 02. 2013, 15:36:39 »
Vobec sa nemusi jednat o narast klientov na AP.
Staci ak si zapne sused starsi router vytuneny 12dBi antenou v mode N-40MHz a bezdratovi klienti v okoli do 200m so smerovymi antenami maju smolu. Latencie lietaju v rytme pouzivania toho rusiaceho routrika. Na 5G pasme to bude zachvilu podobne, ak sa rozsiri 802.11ac. Problem s vybavovanim novych f.mohol byt len zastieraci manever kedze sa nikto doteraz nestazoval.

S tým pravdepodobne problém nebude. Totiž latencia narastá len cez víkend a po obede cez pracovné dni, tj., čo ľudia prídu domov z práce.

15
Sítě / Re:Problémy s vysokými latencemi
« kdy: 11. 02. 2013, 15:11:36 »
At se na me Kapitan nezlobi, ale pokud jde ping na hodnotu pres ctvrt vteriny na dyl nez par sekund jednou za delsi cas, tak to pripojeni je podle me v podstate nepouzitelne. Takze bych si klidne stezoval. Zpetne se snazit z nich vyrazit nejakou pokutu asi nema smysl, ale klidne bych to hral na to, ze odstupuju od smlouvy do budoucna. Ovsem pokud je to jediny ISP v oblasti, tak to je stejne otazka spis filozoficka a nema moc smysl ji resit...

Asi jsem to napsal špatně.
Myslel jsem to tak, že ty latence na té lince u těch zákazníků vznikají na propoji JEJICH MODEM -> MODEM POSKYTOVATELE a to z důvodu ucpání hromadou dat, což není problém poskytovatele.

Pokud by problém vznikal například MODEM ZÁKAZNÍK -> MODEM POSKYTOVATEL --> ROUTER POSTYKOVATELE A {LATENCE} ROUTER POSKYTOVATELE B, pak bych si samozřejmě stěžoval, protože si platím za připojení o určité šířce pásma (pokud není agregované) a mám nárok na odpovídající službu.

Tedy v tomto případě bych si určitě stěžoval, pokud je to někde na uzlech poskytovatele, to rozhodně ano.

Takto. Internet funguje tak, že máme natiahnutý ethernetový kábel do bytu, ktorý mám doma pripojený do routeru. Na druhej strane to má poskytovateľ pripojený niekde na streche do svojho zariadenia, ktoré sa chová ako switch + router. Čiže každý zákazník má nezávislú linku do routeru. Z routeru potom ide cez wifi na prijímač na strane poskytovateľa, kde si už topológiu rieši sám. Cez tracert som zistil, že po bránu poskytovateľa ide všetko v pohode. Problém nastáva až na ďalšom hope, ktorý mimochodom ignoruje ICMP a odpovedá mi až ďalší hop. Čiže za routerom poskytovateľa, tj. bezdrôtové spojenie robí problém, vzhľadom na to, že museli vybavovať nové frekvencie.

Stran: [1] 2 3