[Commotion-dev] Critical services

[Peter Folk]

*Caching Client-Server RSS Proxy* (CSSRSSP)
> In net-accessible areas, servers run a daemon that accepts incoming
> SSH connections (for compression as much as security), over which the
> following protocol is run:
>
>     * client sends monitor<space>N<cr><lf> (for int N) to indicate
>       that it is monitoring N feeds.  N should be 10 digits, 0-padded
>       on the left.
>     * client sends N monitor notifications, consisting of
>       A<space>B<space>C<space>D<cr><lf>, where A is the number of
>       users monitoring the feed, B is the 64-bit UTC timestamp of the
>       last update received for this feed, and C is the number of
>       characters in the feed's URL, and D is that URL.  Numbers are
>       10, 20, and 5 digits, respectively, 0-padded on the left, to
>       make read() as easy as possible
>     * server begins to monitor the feed urls, polling each feed (with
>       higher frequency, down to the feeds minimum update time) in a
>       round-robin fashion weighted by # of monitoring users
>     * When a feed is updated, server sends A<space>B<space>C<cr><lf>,
>       where A is the timestamp of the update (20 digits), B is 0 if
>       this is the full feed or the length of the update diff (in
>       bytes; 10 digits) otherwise, and C is the diff of the RSS feed
>       from the timestamp last reported to be cached by this client
>     * Client periodically updates server with new "monitor N" info.  A
>       user count of 0 removes the feed from the client's list of
>       monitored feeds.  Otherwise, an entry with an already-seen URL
>       updates the timestamp and user count on record for that client
>     * Server caches the most recent list of monitored feeds and
>       metadata in a file, with name == MD5 checksum of the file
>     * Client can resume a cached state (eg, after disconnection) by
>       sending resume<space>A<cr><lf> with the A == the md5sum of a
>       previous state, to which the server should reply either
>       ok<cr><lf> if it has such a state or no<cr><lf> if it does not
>
Notes:

    * the client and server's caches of monitored URLs need to be sorted
      the same to get the same MD5sum.  I suggest sort by URL.
    * in the "When a feed is updated" step, you need to have a boolean B
      (0 if this is the full feed, 1 if sending a diff update), and a
      separate B1 for the length of the update in bytes (left-padded 10
      digit decimal)
    * padding could be zeros or spaces; zeros would normally indicate
      octal so maybe spaces are better
    * Probably need a "nok" response if a line was received that the
      server doesn't grok
    * Probably need an intro "ccsrss v1.2 foo at bar.com" message from the
      server to announce the server version and who to contact if it's
      broken
    * My acronym was wrong =P  Should be CCSRSSP (which to me means, it
      needs a new name)
    * I think that such a client+server could be written in an evening
      in perl (and probably Python, for someone who likes it)
    * this kind of proxy would be useful for any system that's
      periodically connected, wants to monitor multiple RSS feeds, and
      usually has a slow link (like a cell phone).

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20110201/35839745/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 552 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20110201/35839745/attachment.sig>