[ninux-dev] Download e buffering

[Francesco Rapanà]

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> 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> 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20140219/48f9a0ec/attachment-0001.html>