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
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.
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.
3 ukoncovacie zatvorky vtipne to neni
class mojaTrieda {
public:
void a() {
b = 0;
}
private:
int b;
}
}class mojaTrieda {
public:
void a():
b(0) {
}
private:
int b;
}
}
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.
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.