[ninux-dev] Download e buffering

Diego Luca Candido diego.luca.candido at gmail.com
Thu Feb 20 17:28:12 CET 2014


Per questo chiedevo :) Un giorno (lontano) vorro' farmi una box con
raspberry pi, pero' visto che ha il cap alla ethernet rimarro'
fregato.
Cosa ne pensi del cubox per rimpiazzare un p4 stravecchio? Gh

Il 20 febbraio 2014 17:25, Alessandro Gubitosi
<gubi.ale at gotanotherway.com> ha scritto:
> Invece pare che le raspberrypi no.
> -1 RPi (io le odio)
> +1 CuBox
>
> Gubi
>
> Il 20/02/2014 17:04, Diego Luca Candido ha scritto:
>
> http://linux.slashdot.org/story/13/09/03/2223247/tiny-45-cubic-mini-pc-supports-android-and-linux?utm_source=rss1.0mainlinkanon&utm_medium=feed
> pare siano scollegati per fortuna :)
>
> Il 20 febbraio 2014 17:00, Alessandro Gubitosi
> <gubi.ale at gotanotherway.com> ha scritto:
>
> Non lo so.
> Sulle specifiche non è riportato?
>
> Gubi
>
> Il 20/02/2014 15:41, Diego Luca Candido ha scritto:
>
> Alessandro sai se la cubox ha la ethernet gestita dal controller usb?
>
> Il 20 febbraio 2014 15:09, Alessandro Gubitosi
> <gubi.ale at gotanotherway.com> ha scritto:
>
> Ultima news: sono andato alle poste a ritirare la mia cubox.
> 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. 90 EURO) 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> 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 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 :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
>
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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
>
>
>
>
>
> _______________________________________________
> ninux-dev mailing list
> ninux-dev at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/ninux-dev
>



-- 
Diego Luca Candido aka joxer

http://about.me/diego.luca.candido

«Tutto il senso del libro si potrebbe riassumere nelle parole: Quanto
può dirsi, si può dir chiaro; e su ciò, di cui non si può parlare, si
deve tacere»
Ludwig Wittgenstein

«The quieter you become, the more you are able to hear»



More information about the ninux-dev mailing list