I think previous answer are the right ones: this is more of an implementation specific that an requirement by the spec. The Superfeedr hubs is also running on distributed servers with fault tolerance, but that's because we build it that way, not because it's part of the spec.
On Wed, Jul 14, 2010 at 7:52 AM, Alexis Richardson <[email protected]>wrote: > Danny > > On Wed, Jul 14, 2010 at 1:36 AM, Danny Briere <[email protected]> > wrote: > > We are looking at applications of PubSubHubbub that are mission > > critical for businesses. > > What kinds of applications are you looking at? > > > > So while businesses will tolerate some level > > of variable delivery delay, they won't tolerate downtime. They are > > used to 100% or near 100% (five nines) type reliability. > > > > Does PubSubHubbub have support for any type of load distribution, load > > balancing, or fault tolerance? For example, what appears to be a > > single hub to the outside world really consists of several servers > > that share the load, and that keep the hub up and running even if one > > of the servers stops working. > > PSHB is mostly concerned with defining a virtual relationship > ("topic") between publishers and subscribers. This includes basic > lifecycle and delivery properties. It tends to, where possible, > remain silent on certain "implementation details" so that they are > *not ruled out*. For example there are existing techniques for HTTP > server load management. PSHB could talk about such things but it > would then restrict behaviour to a subset of possible hubs, in a way > that is unnecessary for the main goal. > > > > Or, if the load to capture the > > publisher's source info backs up, is there some mechanism to share the > > load out? > > Well, that's quite interesting. Yes you could imagine a 'routing > network' or 'federation' of hubs which could provide more than one way > to get a publication to a subscriber. But this would be an 'implicit' > behaviour; PSHB does not talk about "load" explicitly. > > > > I can see firms listing multiple hubs instead of one in thinking that > > this somehow provides for greater reliability, but I'm not sure that > > does anything but create multiple feeds that subscribers then have to > > true up. Thoughts? > > Well, it's not unlike having multiple email servers. > > alexis >
