[ninux-dev] Download e buffering
Alessandro Gubitosi
gubi.ale at gotanotherway.com
Tue Feb 25 07:13:50 CET 2014
Francesco ho modificato lo script come hai suggerito ma non sembra che
ci siano cambiamenti:
https://github.com/gubi/Ninuxoo-2.0/commit/2ec735cf65ac6494066a9a092a9239a05442738d
Se hai un account github possiamo discuterne di là senza intasare la ML:
https://github.com/gubi/Ninuxoo-2.0/issues/19
Gubi
Il 19/02/2014 13:05, Francesco Rapanà ha scritto:
> Ho effettuato l'iscrizione a Ninux-dev così posso dare il mio contributo.
>
> Le alternative secondo me sono due:
> - file proxy, cioè quello di cui stiamo già parlando (è
> necessario allow_url_fopen = true)
> - smbclient [1] o [2], con la ovvia limitazione che funzionerebbe solo
> con smb e non, ad esempio, con ftp
>
> Il codice che ho inviato "dovrebbe" funzionare, se hai tempo puoi fare
> un piccolo test con due pagine download, la prima con
> readfile_chunked(file_locale) e la seconda con
> readfile_chunked(url_pagina_download1).
>
> Francesco
>
> [1] http://smorgasbork.com/component/content/article/34-web/66-accessing-smb-servers-with-php
> [2] http://sourceforge.net/projects/smbwebclient/
>
>
>
>
> Il giorno 19 febbraio 2014 12:15, Alessandro Gubitosi
> <gubi.ale at gotanotherway.com <mailto:gubi.ale at gotanotherway.com>> ha
> scritto:
>
> Inoltro ninux-dev per "competenza".
>
> Il 19/02/2014 10:14, Francesco Rapanà ha scritto:
>> Nel caso il file si trovi sulla stessa macchina dove gira lo
>> script va bene, ma se il file si trova su un'altra macchina mi
>> pare che il codice non è ancora presente, o sbaglio? In questo
>> caso lo script farebbe @readfile($url_file_altro_nas) o farebbe
>> un redirect verso lo script che gira sul nas che contiene il file?
> Hai ragione non è ancora stato implementato, ma perché sto appunto
> aspettando che mi arrivi un altro device per fare lo sviluppo su
> entrambi, di modo che poi si possa passare agli step successivi.
> Comunque, in teoria parsa l'hash e se c'è il token non guarda in
> locale ma fa una richiesta in broadcast rivolta a quel token, che
> a sua volta parsa l'hash e tira fuori il file.
> Lo script locale re-inoltrerebbe l'output della macchina remota,
> ma non so a questo punto quale potrebbe essere la reazione (se
> appare la finestra di download o fa qualche scherzetto).
> Hai idee migliori?
>
>> In ogni caso readfile credo (non ho testato) dovrebbe dare
>> problemi di memoria con file molto grandi se è abilitato l'output
>> buffering, nei commenti su php c'è la funzione readfile_chunked
>> con il flush. Andrebbe testato sia usando readfile con file
>> locale che con url, mi preoccupa più questo secondo caso perché
>> potrebbe tentare di scaricare prima il file in memoria locale e
>> poi passarlo in output.
>>
>> <?php
>> function readfile_chunked($filename,$retbytes=true) {
>> $chunksize = 1*(1024*1024); // how many bytes per chunk
>> $buffer = '';
>> $cnt =0;
>> // $handle = fopen($filename, 'rb');
>> $handle = fopen($filename, 'rb');
>> if ($handle === false) {
>> return false;
>> }
>> while (!feof($handle)) {
>> $buffer = fread($handle, $chunksize);
>> echo $buffer;
>> ob_flush();
>> flush();
>> if ($retbytes) {
>> $cnt += strlen($buffer);
>> }
>> }
>> $status = fclose($handle);
>> if ($retbytes && $status) {
>> return $cnt; // return num. bytes delivered like
>> readfile() does.
>> }
>> return $status;
>>
>> }
>> ?>
> Avevo notato bene, infatti su questa cosa che mi ero ripromesso di
> parlarne in ML dev.
> Come detto sopra, non lo so, andrebbe testato, e sto aspettando
> questo device <http://imx.solid-run.com/product/cubox-i4-pro/> da
> metà novembre (spedito poi il 2 febbraio).
> Adesso è "/In carico al portalettere del centro postale di RM
> PALESTRINA CSD in data 19-FEB-2014"/), quindi in teoria dovrebbe
> arrivare a giorni, se non oggi stesso.
> Ti terrò aggiornato cmq, perché essendo disoccupato e in risposta
> di notizie lavorative sto lavorando a tempo pieno per Ninux
> <https://github.com/gubi/Ninuxoo-2.0/commits?author=gubi> :D
>
> Grazie comunque per il coinvolgimento e per la funzione che
> testerò sicuramente ;)
> A presto
>
> Gubi
>
>>
>> Il giorno 19 febbraio 2014 08:56, Alessandro Gubitosi
>> <gubi.ale at gotanotherway.com <mailto:gubi.ale at gotanotherway.com>>
>> ha scritto:
>>
>> Parli di una cosa come questa?
>> http://192.168.36.210/Scheda:?ZDQxZDhjZDk4ZjAwYjIwNGU5ODAwOTk4ZWNmODQyN2U6Ly9NdXNpY2EvR2lvcmdpbyBHYWJlci8oMTk4NCkgLSBHYWJlci8wNyAtIElsIFNvY2lhbGUubXAz
>>
>> Non guardare l'ip perché poi dovrà andare su dns anycast
>> ninux (ad es. sarà http://ninuxoo.ninux.org/Scheda:?sde3uhswf3g).
>> Per rendere questo link scaricabile poi anche dall'america ci
>> vorrà magari un url shortener (in ninux ce n'è già uno) e un
>> proxy bgp come anche suggerisci tu, con un altro dns, magari.
>> L'hash contiene già tutto il percorso al file (col token del
>> nas al posto del suo ip), per il resto i nas si trovano in
>> rete da soli via mdns.
>>
>> Lo script imputato al download è questo qui:
>> https://github.com/gubi/Ninuxoo-2.0/blob/master/common/include/funcs/download.php
>> Grazie per la disponibilità del device, ma a meno che non mi
>> dai accesso ssh per correggere gli script che man mano
>> sistemo, meglio aspettare.
>> Sicuramente sarà utile nella fase di collaudo... ;)
>> Notizia: i NAS si potranno collegare tra loro anche se sono
>> remoti, basta indicare l'indirizzo ipv(4|6) o dns... ;)
>>
>> A presto
>> Gubi
>>
>> Il 18/02/2014 22:23, Francesco Rapanà ha scritto:
>>> Se ti può essere utile per i test, ho un synology DS213j.
>>> Al momento sto vedendo come si potrebbe fare una specie di
>>> proxy da installare su un route reflector client in modo da
>>> rendere disponibile all'esterno determinati file / cartelle
>>> interne alla rete.
>>> es: ho un NAS sul nodo xx e un BGP Route Reflector con IP
>>> pubblico sul nodo yy. Se volessi rendere "pubblici"
>>> determinati file del NAS, il proxy potrebbe mostrare la
>>> lista dei file su $IP_pubblico_yy/NAS_xx/ e per il download
>>> credo andrebbe fatto qualcosa con fopen / fread / fwrite
>>>
>>
>
>
>
>
> _______________________________________________
> ninux-dev mailing list
> ninux-dev at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/ninux-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20140225/a27dbbe1/attachment-0001.html>
More information about the ninux-dev
mailing list