This is of course why SIP is better at this sort of thing than HTTP as its designed more for P2P scenarios.
Steve On 19/10/2007, Gregg Wonderly <[EMAIL PROTECTED]> wrote: > > Rob Eamon wrote: > > > > > > --- In > > [email protected]<service-orientated-architecture%40yahoogroups.com> > > <mailto:service-orientated-architecture%40yahoogroups.com>, "Steve > Jones" > > <[EMAIL PROTECTED]> wrote: > > > > > > Guessing at not powerful, RSS/Atom is a pull model, you often want > > > Push as well in pub/sub. > > > > Good point. When searching for tools, keep this in mind as there are > > pub/sub products out there that are pull-only, so if push is essential > > you'll want to make sure the product really does that. For example, the > > webMethods Broker never pushes--all adapters and clients always pull. > > > > On the other hand, pulling frequently enough is often sufficient. > > With many pub/sub usages, the act of connecting, subscribing and then > waiting > for a publish, is similar to pull. When it is different, and scales > better, is > when the subscription actually provides for async delivery. The main issue > with > async delivery, is that it has limitations similar to "call backs" in that > both > network paths producer->consumer and consumer->producer must be routable > in the > context of the utilized connection technologies. > > On the internet, in general, TCP is not fully routable for all > producer->consumer paths to make connections. > > Gregg Wonderly > >
