[ninux-dev] Download e buffering
Alessandro Gubitosi
gubi.ale at gotanotherway.com
Thu Feb 20 15:09:40 CET 2014
Ultima news: sono andato alle poste a ritirare la mia cubox
<http://imx.solid-run.com/product/cubox-i4-pro/>.
L'ho accesa, c'è android 4.3 pre-installato in una micro-sd 4gb classe 4 -_-
Per il resto ha 2 porte usb, 1 micro-usb to rs232, 1 hdmi, 1 lan da
1Gbit, 1 micro-sd, 1 eSata II, 1 porta infrarossi rice-trasmittente,
Wifi e bluetooth integrati.
È un quad core 1GHz da 2gb di RAM, ovviamente ARM.
È calata di prezzo, adesso sta a 125$ (ca. 90EUR) e - a parte la
micro-sd - mi sembra una buona spesa.
Vorrei metterci Debian ma mi manca il cavo USB femmina micro-USB
maschio, shit.
La guida è qui: http://www.solid-run.com/mw/index.php/Debian_armhf_server
Stay tuned
Gubi
Il 19/02/2014 13:53, Alessandro Gubitosi ha scritto:
> Il problema è che né proxy né samba sono ottimali, secondo me.
> Poi samba è il mio più acerrimo nemico, quando ho visto che si poteva
> fare via http ho esultato...
>
> Ultima news: ero di sopra a mangiare e mi sono lisciato col postino,
> che un minuto prima mi ha lasciato la cartolina nella cassetta che c'è
> un pacco per me.
> Poteva chiamare?! Vabbè, devo andarlo a ritirare io, ormai domattina.
> uff...
> 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
>
>
>
> _______________________________________________
> 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/20140220/e2099b40/attachment-0001.html>
More information about the ninux-dev
mailing list