zsync is a file transfer program. It allows you to download a file from
a remote web server, where you have a copy of an older version of the
file on your computer already. zsync downloads only the new parts of the
file. It uses the same algorithm as rsync.
zsync does not require any special server software or a shell account on
the remote system (rsync, in comparison, requires that you have an rsh
or ssh account, or that the remote system runs rsyncd). Instead, it uses
a control file - a .zsync file - that describes the file to be
downloaded and enables zsync to work out which blocks it needs. This
file can be created by the admin of the web server hosting the download,
and placed alongside the file to download - it is generated once, then
any downloaders with zsync can use it. Alternatively, anyone can
download the file, make a .zsync and provide it to other users (this is
what I am doing for the moment).
http://www.vdr-wiki.de/wiki/index.php/Markad-plugin
MarkAd marks advertisements in VDR recordings.
Net::SMS::PChome allows sending SMS messages via http://sms.pchome.com.tw/
An implementation of the Instapaper client API.
(see http://www.instapaper.com/api)
This module provides a backend of WWW::Search to search using
http://search.msn.com/.
It all started when we got some new routers, which told me the
following when trying to upload configuration or download images
from it: The TFTP server doesn't support the blocksize option.
My curiousity was triggered, it took me some reading of RFCs and
other documentation to find out what was possible and what could
be done. Was plain TFTP very simple in its handshake, TFTP with
options was kind of messy because of its backwards capability: The
first packet returned could either be an acknowledgement of options,
or the first data packet.
Going through the source code of src/libexec/tftpd and going through
the code of src/usr.bin/tftp showed that there was a lot of duplicate
code, and the addition of options would only increase the amount
of duplicate code. After all, both the client and the server can
act as a sender and receiver.
At the end, it ended up with a nearly complete rewrite of the tftp
client and server. It has been tested against the following TFTP
clients and servers:
- Itself (yay!)
- The standard FreeBSD tftp client and server
- The Fedora Core 6 tftp client and server
- Cisco router tftp client
- Extreme Networks tftp client
It supports the following RFCs:
RFC1350 - THE TFTP PROTOCOL (REVISION 2)
RFC2347 - TFTP Option Extension
RFC2348 - TFTP Blocksize Option
RFC2349 - TFTP Timeout Interval and Transfer Size Options
RFC3617 - Uniform Resource Identifier (URI) Scheme and Applicability
Statement for the Trivial File Transfer Protocol (TFTP)
It supports the following unofficial TFTP Options as described at
http://www.compuphase.com/tftp.htm:
blksize2 - Block size restricted to powers of 2, excluding protocol headers
rollover - Block counter roll-over (roll back to zero or to one)
From the tftp program point of view the following things are changed:
- New commands: "blocksize", "blocksize2", "rollover" and "options"
- Development features: "debug" and "packetdrop"
If you try this tftp/tftpd implementation, please let me know if
it works (or doesn't work) and against which implementaion so I can
get a list of confirmed working systems.
NNTP server daemon, and clients for transferring news articles.
Seahub is the web frontend for seafile-server.
Audio::MPD gives a clear object-oriented interface for talking to and
controlling MPD (Music Player Daemon) servers. A connection to the MPD
server is established as soon as a new Audio::MPD object is created.
Note that the module will by default connect to mpd before sending any
command, and will disconnect after the command has been issued. This scheme
is far from optimal, but allows us not to care about timeout disconnections.
/!\ Note that Audio::MPD is using high-level, blocking sockets. This means
that if the mpd server is slow, or hangs for whatever reason, or even
crash abruptly, the program will be hung forever in this sub. The
POE::Component::Client::MPD module is way safer - you're advised to use it
instead of Audio::MPD. Or you can try to set conntype to $REUSE (see
Audio::MPD constructor for more details), but you would be then on your
own to deal with disconnections.
ZNibbles is a multi-player networked game. It is based on the old
nibbles game: you've got a worm, eat nibbles and get your worm growing.
Several players can play together, each of them controlling its own worm
on its own computer.
There is theoretically an unlimited number of simultaneous players, it's
more a matter of network speed. It has been tested with more than 10
players and it was real fun :) ZNibbles is written for Unix. It has been
tested under Linux, SunOS, Solaris and Irix. The game can run either
directly on top of X11, use the GTK+ toolkit (get it on the GTK+ site)
or use the Motif toolkit (get a good Motif free implementation called
LessTif)
Once compiled, you get the files:
nibbles : the ZNibbles server
gznibbles : the ZNibbles GTK+ client
znibblesX : the ZNibbless X11-only client (poor)
Run "nibbles" first as the ZNibbles server, and then run its clients to
play.