File letőltés
Tisztelet!
Tudna valaki abban segíteni, hogy az alábbi kódot, hogy lehet úgy módisítanom, hogy fennmaradjon az oldal és a kliens között az interakció?
(ez egy külön fileban fut, mondjuk download.php de közben minden más meghal az oldalon)Főként azért szeretném ezt a kódot alkalmazni, mert a nagy fájlok letöltésévél meggyűlt a bajom és ez tökéletesen megfelelt erre a célra.
Válaszaitok előre is köszönöm.
■ Tudna valaki abban segíteni, hogy az alábbi kódot, hogy lehet úgy módisítanom, hogy fennmaradjon az oldal és a kliens között az interakció?
(ez egy külön fileban fut, mondjuk download.php de közben minden más meghal az oldalon)
header('Content-Description: File Transfer');
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename=' . $filename;
header('Content-Transfer-Encoding: binary');
header('Expires: 0');
header('Cache-Control: must-revalidate, post-check=0, pre-check=0');
header('Pragma: public');
header('Content-Length: ' . $filesize);
ob_clean();
$handle = fopen($filedir, 'rb');
while (!feof($handle)){
echo fread($handle, 5242880);
ob_flush();
flush();
sleep(1);
}
fclose($handle);
Válaszaitok előre is köszönöm.
Hali!
target="_blank"attribútummal új lapon / ablakban "nyitni" a letöltést, így az eredeti megmarad.Mondjuk elvileg ugyanazon ablakban is meg kéne maradnia, csak elindul egy letöltés, de gyanítom, hogy nem ez a teljes download.php, így nem látom a konkrét okot.
Interakció alatt ugye azt értetted, hogy marad felület, ahova tud kattintani?
Köszi a választ, némi keresés
Van egy adott oldal, mindenféle dinamikus oldal betöltessél stb.
Van egy linkünk ami a download.php-re mutat (és a sleep valóban a korlátozást hivatott előidézni). És amíg a download.php pörög (külön lapon), masszívan dolgozik a php és magán az oldalon közbe megszűnik minden server irányába történő lekérdezés mert a download.php befoglalja. Mint kiderült a php nem képes párhuzamos munkamenet kezelésre. Ezért megoldásként egy redirectelt vhostot hoztam létre ami mindig másik vhoston kezdi el betölteni a tartalmat (így működik a párhuzamosítás).
Tehát ugyan a probléma megoldódott, azért érdekelne, hogy van e erre pure megoldás.
Továbbá nagyon köszönöm a segítőkész válasz kolléga : )
Azért ez így nem feltétlenül
Most nem tudok linket hozni, de a php multi threading (miért három szó, azt nem tudom) kifejezésre keresve az elsők közt van egy jó régi stackoverflow találat, amiben ezt részletezik.
Ha maga a php egy szálon is fut, a web szervernek szerintem meg lehet mondani, hogy hány "worker" fusson.
Pythonnál is ez volt a bajom, míg rá nem jöttem, hogy tud ilyet: a python kód egy szálon fut, de sok példányt indít az nginx.
Szerintem
Viszont ez is csak parancssori módban működik (egyébként úgy tűnik, már nem fejlesztik, elavult), PHP dokumentációból:
The pthreads extension cannot be used in a web server environment. Threading in PHP is therefore restricted to CLI-based applications only.
Egyébként a php önmagában (és webszerver "mögött" is) multi threaded, nem azon múlik a fenti "homokórázás". Talán valamilyen webszerver-beállításon, de ahhoz a részéhez nem értek eléggé.
Valószínű. Azt hiszem, privát
A végét viszont nem értem. Hogyhogy önmagában multithtraded?
Szerintem a PHP nagyon nem az. Pláne így, hogy azt a modult/library-t/stb nem is fejlesztik már.
A mt azt jelenti, hogy pl közös memórián, egyéb erőforrásokon osztoznak a szálak. Ha csak a processzeket listázod, csak egy processzt látsz. A multiprocess környezet más (szerintem ez van PHP esetében), azok önálló programként futnak.
De a PHP önmagában szerintem ezt sem tudja. Az elé rakott web szerver indít több processzt.
(Azért jó lenne, ha ezt valaki megerősítené, mert már túl sok dolog esett ki nekem :(( )
Pythonnal én egy Flask nevű keretrendszert használok, annak már sikerült meglepetést okoznia. Valódi mt működést akartam egy teszt kedvéért, akkor derült ki, hogy a flask saját web szervere tényleg több szálon futtatja az applikációt.
multithtraded
Viszont ezzel rávezettél a megoldásra, l. lentebb.
A probléma: jelen esetben leginkább a session, mert az bizony természeténél fogva nem "mt-képes", az üzleti logikájából fakadóan egyszerre csak egy szál férhet hozzá, mert megváltoztathatja, ezért a session_start lockolja, a session_write_close "engedi el".
Vagyis a fenti probléma az, hogy a lassított letöltés ameddig fut, addig másik szál nem fér hozzá ugyanahhoz a session-höz.
Megoldás: a lassú szál ne használjon sessiont. Ha felhasználóhoz - jogosultsághoz kötött a letöltés és mindenképpen lassítani kell, akkor pl a link kirakásakor generálni kell egy ideiglenes tokent, amihez a szükséges adatok adatbázisban vannak, a letöltés indításakor ezt kell ellenőrizni és a további felhasználását tiltani. Így ez a szál nyugodtan lehet lassú, nem blokkolja a másik szál session-ét.
A lassításra pedig sokkal jobb Endyl megoldása, vagy valami ahhoz hasonló.
A több szál és a több példány
Nagyon nem mindegy, hogy több szál vagy több processz a több példány.
A mt (egyik?) lényege, hogy kisebb "költséggel" tud párhuzamos működést biztosítani, mint a mp (multiprocessing). Viszont vannak elég komoly megkötései, amiket így fejből nem tudnék felsorolni. Annyi biztos, hogy mt programokat csak ú.n. "thread safe" alkatrészekből szabad összerakni, különben elég fura, random jelentkező hibákat produkálhat a program.
Ami példákat hoztál, azok multiprocess környezetben működnek.
Egy mq olvasás még elképzelhető threadként, csak viszonylag kevés értelme van ilyen felállásban, de egy cron job már mindenképpen külön processz.
olvasnivaló - a browseres példája pont nem jó, mert manapság biztonsági okok miatt önálló processzbrn futnak a tabok. :)
Rate-Limit?
mod_ratelimit? Link).