<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Paremus ServiceFabric on EC2 &#8211; day 1</title>
	<atom:link href="http://blog.thestateofme.com/2009/12/14/paremus-servicefabric-on-ec2-day-1/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.thestateofme.com/2009/12/14/paremus-servicefabric-on-ec2-day-1/</link>
	<description>IT mixology and other thoughts about tech, life the universe and everything</description>
	<lastBuildDate>Fri, 03 Feb 2012 10:17:56 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: rbpasker</title>
		<link>http://blog.thestateofme.com/2009/12/14/paremus-servicefabric-on-ec2-day-1/#comment-373</link>
		<dc:creator><![CDATA[rbpasker]]></dc:creator>
		<pubDate>Mon, 21 Dec 2009 18:40:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thestateofme.com/?p=204#comment-373</guid>
		<description><![CDATA[Hi Richard -- 

if the problem is non-propogation of multicast, gossiper is a solution. for some reason a lot of people seem to confuse &quot;something like&quot; with &quot;definitely use,&quot; and of course i didn&#039;t mean it that way.

i don&#039;t know what other problems you&#039;re trying to solve.

--b]]></description>
		<content:encoded><![CDATA[<p>Hi Richard &#8212; </p>
<p>if the problem is non-propogation of multicast, gossiper is a solution. for some reason a lot of people seem to confuse &#8220;something like&#8221; with &#8220;definitely use,&#8221; and of course i didn&#8217;t mean it that way.</p>
<p>i don&#8217;t know what other problems you&#8217;re trying to solve.</p>
<p>&#8211;b</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: richard</title>
		<link>http://blog.thestateofme.com/2009/12/14/paremus-servicefabric-on-ec2-day-1/#comment-372</link>
		<dc:creator><![CDATA[richard]]></dc:creator>
		<pubDate>Mon, 21 Dec 2009 17:53:36 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thestateofme.com/?p=204#comment-372</guid>
		<description><![CDATA[Bob,

Long time! 

A couple of comments / thoughts. 

One needs to be careful w.r.t. multicast. At layer II - IGMP based multicast is usually fine in the enterprise. However - as soon as you move to layer III - as you suggest - you are into a whole new level of pain. Protocol Independent Multicast (PIM) is not usually supported across the backbone etc etc. 

Also whatever the group protocol - the participating endpoints must be discovered; note that Gossiper allows for multicast discovery  - see synchronized void join(InetAddress from).
So local multicast discovery - used in conjunction with a &#039;smart overlay&#039; is a good approach. 

With respect to the Gossip protocol itself - it has the same advantages and disadvantages as its social namesake. No doubt useful for propagating information across an unstructured population - its current popularity is a function of Amazon&#039;s use of it (also Astrolabe) - rather than perhaps intrinsic suitability. There are more efficient lower latency messaging approaches that may be used with &#039;smart&#039; populations of self-organizing cloud resource.

We will be making a press release early in the New Year which touch upon this area. 

Best Wishes / Merry Xmas


Richard]]></description>
		<content:encoded><![CDATA[<p>Bob,</p>
<p>Long time! </p>
<p>A couple of comments / thoughts. </p>
<p>One needs to be careful w.r.t. multicast. At layer II &#8211; IGMP based multicast is usually fine in the enterprise. However &#8211; as soon as you move to layer III &#8211; as you suggest &#8211; you are into a whole new level of pain. Protocol Independent Multicast (PIM) is not usually supported across the backbone etc etc. </p>
<p>Also whatever the group protocol &#8211; the participating endpoints must be discovered; note that Gossiper allows for multicast discovery  &#8211; see synchronized void join(InetAddress from).<br />
So local multicast discovery &#8211; used in conjunction with a &#8216;smart overlay&#8217; is a good approach. </p>
<p>With respect to the Gossip protocol itself &#8211; it has the same advantages and disadvantages as its social namesake. No doubt useful for propagating information across an unstructured population &#8211; its current popularity is a function of Amazon&#8217;s use of it (also Astrolabe) &#8211; rather than perhaps intrinsic suitability. There are more efficient lower latency messaging approaches that may be used with &#8216;smart&#8217; populations of self-organizing cloud resource.</p>
<p>We will be making a press release early in the New Year which touch upon this area. </p>
<p>Best Wishes / Merry Xmas</p>
<p>Richard</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Swan</title>
		<link>http://blog.thestateofme.com/2009/12/14/paremus-servicefabric-on-ec2-day-1/#comment-371</link>
		<dc:creator><![CDATA[Chris Swan]]></dc:creator>
		<pubDate>Mon, 21 Dec 2009 16:46:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thestateofme.com/?p=204#comment-371</guid>
		<description><![CDATA[Thanks Bob,

The whole experience has been somewhat reminiscent of getting clustering to work on WLS 6 ;-)

I guess one of the nice things about using a VPN overlay is that once you do get multicast working on it (see day 4) then you&#039;re no longer beholden to the vagaries of whatever you network team (or cloud) choose to support.

I&#039;ve passed your Gosspier suggestion onto the Paremus team.]]></description>
		<content:encoded><![CDATA[<p>Thanks Bob,</p>
<p>The whole experience has been somewhat reminiscent of getting clustering to work on WLS 6 ;-)</p>
<p>I guess one of the nice things about using a VPN overlay is that once you do get multicast working on it (see day 4) then you&#8217;re no longer beholden to the vagaries of whatever you network team (or cloud) choose to support.</p>
<p>I&#8217;ve passed your Gosspier suggestion onto the Paremus team.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bob pasker</title>
		<link>http://blog.thestateofme.com/2009/12/14/paremus-servicefabric-on-ec2-day-1/#comment-368</link>
		<dc:creator><![CDATA[bob pasker]]></dc:creator>
		<pubDate>Mon, 21 Dec 2009 15:36:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.thestateofme.com/?p=204#comment-368</guid>
		<description><![CDATA[Nice job Chris.

Relying in multicast for clustering almost always fails because so many LANs don&#039;t support it, and it doesn&#039;t work over WANs.

they should replace it with something like Gosspier from Cassandra

https://svn.apache.org/repos/asf/incubator/cassandra/trunk/src/java/org/apache/cassandra/gms/Gossiper.java]]></description>
		<content:encoded><![CDATA[<p>Nice job Chris.</p>
<p>Relying in multicast for clustering almost always fails because so many LANs don&#8217;t support it, and it doesn&#8217;t work over WANs.</p>
<p>they should replace it with something like Gosspier from Cassandra</p>
<p><a href="https://svn.apache.org/repos/asf/incubator/cassandra/trunk/src/java/org/apache/cassandra/gms/Gossiper.java" rel="nofollow">https://svn.apache.org/repos/asf/incubator/cassandra/trunk/src/java/org/apache/cassandra/gms/Gossiper.java</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

