[ninux-dev] Download e buffering
Alessandro Gubitosi
gubi.ale at gotanotherway.com
Wed Feb 26 00:36:23 CET 2014
Ciao,
sì, direi che ogni buon nerd ha decisamente il suo account su github,
quindi buono smanettamento ;)
Sinceramente non sono molto esperto di buffering, quindi mi sono
limitato a fare il download monitorando la net-console di firebug...
Puoi provare con questo file
<http://192.168.36.210/Scheda:?ZDQxZDhjZDk4ZjAwYjIwNGU5ODAwOTk4ZWNmODQyN2U6Ly9WaWRlby9GaWxtL1NhZ2E6IFRoZSBNYXRyaXgvTWF0cml4ICgxOTk5IC0gQW5keSBlIExhcnJ5IFdhY2hvd3NraSkuYXZp>,
almeno fino a che non mi si impalla la odroid.
Il file sta nel NAS (192.168.36.200) che è montato in maniera permanente
su una odroid X2 (192.168.36.210).
Ad essere sincero mi sembra che la situazione sia nettamente peggiorata
perché almeno prima se lasciavo fare il download senza toccare altro non
si incantava.
Se si incanta te ne accorgi perché semplicemente smette di pingare.
Fammi sapere
Gubi
Il 25/02/2014 22:27, Francesco Rapanà ha scritto:
> Non ho l'account ma lo creo prima possibile.
> Quali test hai effettuato? Hai a disposizione un file grande da
> rendere disponibile al download?
> Probabilmente se il file è in locale e non è attivo l'output buffering
> non dovrebbero esserci differenze, credo che la differenza si noti se
> il file è remoto e/o c'è output buffering.
>
>
>
> Il giorno 25 febbraio 2014 07:13, Alessandro Gubitosi
> <gubi.ale at gotanotherway.com <mailto:gubi.ale at gotanotherway.com>> ha
> scritto:
>
> 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 <mailto: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/20140226/8610553e/attachment-0001.html>
More information about the ninux-dev
mailing list