sixserv blog

Habe gestern das erste testing Release von vBrowseFile veröffentlicht.

Installation(auszug aus der README-Datei):

- install HTTP_Download with pear
    For Debian you could do this with:
        # aptitude install php-pear
        # pear install --alldeps HTTP_Download

- Make sure .htaccess Files are used
    Change VHost setting: "AllowOverride All"

- Download vBroweFile Files to an webroot/vhost-root:
    Download an packaged vbf version.
    - or -
    Checkout the latest SVN version: (will create vbrowsefile/ directory)
    $ svn co svn://mount.at/geekosphere/vbrowsefile/trunk vbrowsefile/

- Make sure the following Directories are writeable by Webserver:
    /flatfiles
    /flatfiles/cache
    /flatfiles/cache/tracks
    /flatfiles/userquery
    /smarty/templates_c

- Go with your browser to the setup.php script:
    e.g. http://example.com/vbrowsefile/setup.php

- Now you could login, change configuration, add some virtual directories
  and create some normal users

Tagged: Coding, PHP, vbrowsefile

vBrowseFile uses a slightly modificated Version of HTTP_Download. HTTP_Download is a Pear-Module to send local Files to Browser:

Provides an interface to easily send hidden files or any arbitrary data to HTTP clients. HTTP_Download can gain its data from variables, files or stream resources.

It features:
- Basic caching capabilities
- Basic throttling mechanism
- On-the-fly gzip-compression
- Ranges (partial downloads and resuming)
- Delivery of on-the-fly generated archives through Archive_Tar and Archive_Zip
- Sending of PgSQL LOBs without the need to read all data in prior to sending

I added a ThrottleCallback functionality to HTTP_Download, a function that is executed after the BufferSize is transferred and the ThrottleDelay Time is waited. Modifications in HTTP/Download.php:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

    var $throttleCallback = null;
    [...]
    function setThrottleCallback($callback)
    {
        $this->throttleCallback = $callback;
    }
    [...]
    function callThrottleCallback()
    {
        // execute callback
        if($this->throttleCallback != null)
        {
            $callback = $this->throttleCallback;
            $callback($this);
        }
    }
    [...]
    function sendChunk($chunk, $cType = null, $bound = null)
    {
    [...]
        // right after sleep is ex
        $this->callThrottleCallback();
    [...]
    }

This Callback could be used to track the download progress and to create a real bandwidth limitation. HTTP_Download supports a basic throttling mechanism to limit the bandwidth, but this only works for one connection, so e.g. you could limit 2 downloads to each 100 KiB/s but not all 2 downloads to each 50 KiB/s to limit the overall bandwidth to 100 KiB/s, instead it would be 200 KiB/s.
For this real bandwidth limiting you could use Apache modules like cband(seems not to work with php) or mod-bw, or you could use tc. Siyb from Geekosphere wrote an article about mod-bw: Limit Bandwidth per vHost in Apache2 (on Debian/Lenny)

Another possible way to limit the bandwidth is to implement it with HTTP_Download. The Theory is, to track all running downloads and change the BufferSize to := download limit * delay / active connections every seconds with the callback function from above.

More detailed:

• We generate a random connection id(i call it rcid) for the tracking file.
• ThrottleDelay is set to 1 seconds.
• BufferSize is set to 100 KiB * 1 Seconds * 1024 to setup a maximum speed of 100KiB/s.
• The Callback would now be executed every 1 Seconds:
  • create or overwrite our own rcid file with time() inside.
  • search for other rcid files and check there time-stamp. tracking files older then 5 seconds would be deleted.
  • count all rcid tracking files. e.g. 2 means there 2 open download connections.
  • change the BufferSize. e.g. for 2 open connections: (100 KiB * 1 Seconds * 1024) / 2

This would limit the overall bandwidth of all active connections to a maximum of 100 KiB/s with a delay of ~ <5 Seconds. Without any Apache Modules or other standalone traffic sharping tools. For small installations this should work with no problem but for bigger installations a more efficient traffic shaping tool would be more effective.

Example Implementation: Read the rest of this entry »

Tagged: Coding, Networking, PHP, vbrowsefile

Mit Twitter kann ich sehr leicht über meinen rbot publizieren, damit ich in der selben Frequenz auch soup.io verwende, was für spezielleren Content besser geeignet ist, muss es schon ebenfalls über den rbot funktionieren. Nach langem suchen stellte ich überrascht fest das das große Web 2.0 Projekt Soup.io keine API zum leichten publizieren(außerhalb des Browsers) besitzt. Da muss also erstmal eine art API gestrickt werden. Mit Hilfe von Mechanize baute ich die Browseranfragen nach und fasste es in einer kleinen Ruby Klasse zusammen. Es wird nicht jeder Content-Typ unterstützt aber für meine Zwecke reicht dies völlig aus. Dann noch schnell eine rbot-Plugin Klasse zum bedienen der eigenen “API” und fertig war die erste Version meines soupio-Plugins.
Hier eine Liste der möglichen Befehle(Argumente in eckigen Klammern sind Optional):

1
2
3
4
5
6
7
8
9
10
11

soup identify <username> <password> => Jeder Benutzer im Channel kann dem Bot seine 
Soup.io-Zugangsdaten im Query mitteilen.
 
soup login => Neuer Login falls die gespeicherte SessionId verloren 
oder ungültig wird. (Normalerweise nicht notwendig.)
 
soup link <url> [<title>]
soup image <url> [<description>]
soup text <text>
soup quote <source>: <quote>
soup video <youtube-url> [<description>]

Die SoupIoClass-Klasse kann übrigens auch außerhalb des Plugins, in jeder Ruby-Anwendung verwendet werden. Hier eine kleine Referenz, diesmal die optionalen Argumente in spitzen Klammern:

1
2
3
4
5
6

soup = SoupIoClass.new('[Username]', '[Password]'<, '[Domain]', '[Session-ID]'>)
soup.new_link '[URL]'<, '[Title]', '[Description]'>
soup.new_image '[URL]'<, '[Description]'>
soup.new_text '[Text]'<, '[Title]'>
soup.new_quote '[Quote]'<, '[Source]'>
soup.new_video '[Youtube-URL]'<, '[Description]'>

Die Domain und SessionId kann mit soup.sessid und soup.domain abgefragt werden. Die SessionId ist praktisch unbegrenzt lange haltbar, weshalb diese beiden Daten zwischengespeichert werden können um bei häufiger Nutzung der Klasse sich nicht ständig neu Anmelden zu müssen.

Die Version 0.1 ist bereits veröffentlicht, ich muss mich noch um die Validierung und Fehlerabfragen kümmern aber sonst sollte das Plugin schon funktionieren. Fehler bitte bei mir Melden.
Update: Version 0.2 veröffentlicht. (nur kleine Änderungen)
Update: Version 0.3 veröffentlicht. (Bugfix für eigene Domains)
Update: Version 0.4 veröffentlicht. (Änderungen an soup.io)

Tagged: bot, Coding, irc, plugin, RBot, Ruby, soup.io, web2.0