<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: On Blog Pinging (again)</title>
	<atom:link href="http://journal.paul.querna.org/articles/2006/01/30/on-blog-pinging-again/feed/" rel="self" type="application/rss+xml" />
	<link>http://journal.paul.querna.org/articles/2006/01/30/on-blog-pinging-again/</link>
	<description>Now with less async io</description>
	<pubDate>Wed, 07 Jan 2009 19:09:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Greg Gershman</title>
		<link>http://journal.paul.querna.org/articles/2006/01/30/on-blog-pinging-again/comment-page-1/#comment-32</link>
		<dc:creator>Greg Gershman</dc:creator>
		<pubDate>Thu, 02 Feb 2006 08:10:30 +0000</pubDate>
		<guid isPermaLink="false">#comment-32</guid>
		<description>"Anyways, At $work we do not currently accept pings from anyone. Instead we crawl every site in our system, every 30 minutes. Its not that hard, honestly, thanks to memcached and conditional http requests. (Oh, and lots of bandwidth)."

This does help Bloglines maintain a fresh index, but there are various ways that your algorithm could be improved that would save others bandwidth and respect established protocols such as the RSS 2.0 channel-level ttl element.  Intelligent spacing of visits, based on historical frequency of posting would also not be a bad thing.   For systems with lots of feeds, a deluge of 10 requests per second, twice an hour, on top of normal loads of traffic can be  crippling.  We've had to start sending 304's to Bloglines during peak hours.</description>
		<content:encoded><![CDATA[<p>&#8220;Anyways, At $work we do not currently accept pings from anyone. Instead we crawl every site in our system, every 30 minutes. Its not that hard, honestly, thanks to memcached and conditional http requests. (Oh, and lots of bandwidth).&#8221;</p>
<p>This does help Bloglines maintain a fresh index, but there are various ways that your algorithm could be improved that would save others bandwidth and respect established protocols such as the RSS 2.0 channel-level ttl element.  Intelligent spacing of visits, based on historical frequency of posting would also not be a bad thing.   For systems with lots of feeds, a deluge of 10 requests per second, twice an hour, on top of normal loads of traffic can be  crippling.  We&#8217;ve had to start sending 304&#8217;s to Bloglines during peak hours.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ed Kohler</title>
		<link>http://journal.paul.querna.org/articles/2006/01/30/on-blog-pinging-again/comment-page-1/#comment-31</link>
		<dc:creator>Ed Kohler</dc:creator>
		<pubDate>Tue, 31 Jan 2006 14:29:08 +0000</pubDate>
		<guid isPermaLink="false">#comment-31</guid>
		<description>I don't think proactive pinging is anything like email spoofing. Spoofing has two victims: those mislead by the spoofed email, and the person/business who's email was spoofed.

Proactive pinging, on the other hand, rewards blogs who've been mentioned on other blogs by giving them proper credit for the links, and drives additional traffic to the linker's previously unpinged blog. Blog search engines also benefit because it adds additional link data into their systems, allowing them to rank sites properly.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think proactive pinging is anything like email spoofing. Spoofing has two victims: those mislead by the spoofed email, and the person/business who&#8217;s email was spoofed.</p>
<p>Proactive pinging, on the other hand, rewards blogs who&#8217;ve been mentioned on other blogs by giving them proper credit for the links, and drives additional traffic to the linker&#8217;s previously unpinged blog. Blog search engines also benefit because it adds additional link data into their systems, allowing them to rank sites properly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Sandler</title>
		<link>http://journal.paul.querna.org/articles/2006/01/30/on-blog-pinging-again/comment-page-1/#comment-30</link>
		<dc:creator>Dan Sandler</dc:creator>
		<pubDate>Tue, 31 Jan 2006 00:04:10 +0000</pubDate>
		<guid isPermaLink="false">#comment-30</guid>
		<description>Hey, thanks for noticing our project! A couple of follow-up notes on FeedTree:
&lt;ol&gt;&lt;li&gt;
Yeah, Java is a pain.  Unfortunately, most of the leading academic research into scalable peer-to-peer overlays is done in Java, so that's the platform FeedTree is built on.  (Yes, I know BitTorrent is Python; it's also really the wrong kind of p2p system for this application.)  Fortunately, some of the future work of the &lt;a href='http://freepastry.org/' rel="nofollow"&gt;FreePastry&lt;/a&gt; team includes developing a new runtime-independent binary wire protocol, so one could develop a compatible Pastry implementation in some other language (FeedTree then being layered atop that).
&lt;/li&gt;
&lt;li&gt;It's true, we could have made digital signatures mandatory on the part of publishers.  We chose not to for a couple of reasons, chief among them adoption. We figured it would be daunting enough to get feed owners to install a persistent daemon, let alone messing around with certificates. Maybe it's a flimsy reason, but we're eager to do whatever we can to spur adoption. This is a problem domain (feed updates on a push schedule, fixing the "ping crisis", keeping the bandwidth manageable) that can really benefit from peer-to-peer techniques.  
&lt;p&gt;
[It's also worth noting that sometimes you can't sign things.  When there's no authoritative publisher pushing feed content to the FeedTree network (what we call a "conventional" or "legacy" feed), FeedTree subscribers self-organize into a collaborative polling scheme (staggering their requests, and sharing new events with one another).  The thing is, none of them is really authoritative, so it's not meaningful for them to sign their content; as such, if you use FeedTree, you'll see that these shared events carry no signature and can't be authenticated.]
&lt;/li&gt;&lt;/ol&gt;
If, in the worst (best?) case, FeedTree should become so popular that spammers start to try to fill it with spam pings, there are a couple of properties of the network that should make this a losing proposition, long-term:
&lt;ul&gt;&lt;li&gt;If you're not subscribed to the feed, you don't see its updates.  If a user injects a bunch of bogus updates for a splog nobody cares about, those updates won't reach any eyeballs. There will be some network overhead if this happens, but it should be limited to a small portion of the system (and, again, no users will see any of the spam pings).
&lt;li&gt;If spammers start injecting junk into legit feed channels, it's pretty easy to say, "OK, for this feed I'll ignore any unsigned updates."  If FeedTree's ever so popular that this scenario becomes reality, the publishers of those spammed feeds will have incentive to reach their readers using FeedTree, and will hopefully invest the effort to start pushing signed updates.
&lt;/ul&gt;</description>
		<content:encoded><![CDATA[<p>Hey, thanks for noticing our project! A couple of follow-up notes on FeedTree:</p>
<ol>
<li>
Yeah, Java is a pain.  Unfortunately, most of the leading academic research into scalable peer-to-peer overlays is done in Java, so that&#8217;s the platform FeedTree is built on.  (Yes, I know BitTorrent is Python; it&#8217;s also really the wrong kind of p2p system for this application.)  Fortunately, some of the future work of the <a href='http://freepastry.org/' rel="nofollow">FreePastry</a> team includes developing a new runtime-independent binary wire protocol, so one could develop a compatible Pastry implementation in some other language (FeedTree then being layered atop that).
</li>
<li>It&#8217;s true, we could have made digital signatures mandatory on the part of publishers.  We chose not to for a couple of reasons, chief among them adoption. We figured it would be daunting enough to get feed owners to install a persistent daemon, let alone messing around with certificates. Maybe it&#8217;s a flimsy reason, but we&#8217;re eager to do whatever we can to spur adoption. This is a problem domain (feed updates on a push schedule, fixing the &#8220;ping crisis&#8221;, keeping the bandwidth manageable) that can really benefit from peer-to-peer techniques.
<p>
[It's also worth noting that sometimes you can't sign things.  When there's no authoritative publisher pushing feed content to the FeedTree network (what we call a "conventional" or "legacy" feed), FeedTree subscribers self-organize into a collaborative polling scheme (staggering their requests, and sharing new events with one another).  The thing is, none of them is really authoritative, so it's not meaningful for them to sign their content; as such, if you use FeedTree, you'll see that these shared events carry no signature and can't be authenticated.]
</p>
</li>
</ol>
<p>If, in the worst (best?) case, FeedTree should become so popular that spammers start to try to fill it with spam pings, there are a couple of properties of the network that should make this a losing proposition, long-term:</p>
<ul>
<li>If you&#8217;re not subscribed to the feed, you don&#8217;t see its updates.  If a user injects a bunch of bogus updates for a splog nobody cares about, those updates won&#8217;t reach any eyeballs. There will be some network overhead if this happens, but it should be limited to a small portion of the system (and, again, no users will see any of the spam pings).
</li>
<li>If spammers start injecting junk into legit feed channels, it&#8217;s pretty easy to say, &#8220;OK, for this feed I&#8217;ll ignore any unsigned updates.&#8221;  If FeedTree&#8217;s ever so popular that this scenario becomes reality, the publishers of those spammed feeds will have incentive to reach their readers using FeedTree, and will hopefully invest the effort to start pushing signed updates.
</li>
</ul>
]]></content:encoded>
	</item>
</channel>
</rss>
