Lots of these articles are related to google wave. Check out the wave
protocol and video. (docs uses same underlying tech as wave, for doc
editing)
On Mar 11, 2011 10:12 PM, "Eloi Du Bois" wrote:
Thank you very much !
Very interesting !
- Eloi.
2011/3/11 Joshua Foster
>
> In addition to rea
rmination was initiated. When new connection was created and the
> termination was not yet over, the new subscription was accidentally pushed
> to the pipe being closed at the moment. I've blocked any input/output from
> the socket till the pipe is re-created.
>
> Pleas
Hi Martin,
On Tue, Feb 1, 2011 at 12:04 PM, Martin Sustrik wrote:
> I think I've found the problem you were experiencing.
>
> The XSUB socket was forwarding all subsctiptions upstream irrespective of
> whether they've duplicated existing subscriptions or not.
>
> I've fixed the problem in sub-fo
PM, Martin Sustrik wrote:
> Gerard,
>
> I am having problem reproducing the behaviour you are seeing.
>
> I am attaching my test programs (publisher, subscriber and the
> configuration file for forwarder device).
>
> Are you able to reproduce the behaviour usi
er socket until
the broker is killed (killed, not restarted).
As soon as the broker is killed, the PUB suddenly picks up all pending
messages and prints the sub requests (debug).
This condition is not consistent. Sometimes the broker is restarted and it
just works. Only sometimes after f
lso, the subscription pipe is dropped and re-instantiated on the PUB side.
> This will allow XPUB socket to drop the corresponding subscriptions from its
> map/trie when subscriber shuts down.
>
> The changes are applied to sub-forward branch.
>
> Let me know whether it works as
's probably usually not a
problem, but only in circumstances where there are many
volatile / temporary subscriptions in use.
Rgds,
--
Gerard Toonstra
---
http://www.radialmind.org
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
bscriber goes away. In effect,
the only way to get rid of a subscription is by an explicit unsubscribe.
( i.e... for longer uptimes and temporary topics, it is possible that a
broker starts to receive and send more data than needed )
Not sure if that is deemed important to 0MQ to resolve.
Rgds,
x27;s the patch that should trigger subscriptions to be re-sent
> when socket re-connects to a particular peer. However, this patch wasn't
> tested yet.
>
> Martin
>
--
Gerard Toonstra
---
http://www.radialmind.org
to any new outbound pipe.
>
> Martin
>
--
Gerard Toonstra
---
http://www.radialmind.org
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
a patch
> that attempts to do that. Peer review would be appreciated.
>
> 2. Implement re-sending of subscriptions in case of re-connect. Also
> post-hoc subscriptions (when actual connect happens after the subscription
> itself) etc.
>
> 3. Implemen
;ve added fq_t to xpub_t as proposed above.
>
> All of that is committed to the master. You are added to AUTHORS file.
>
> Martin
>
--
Gerard Toonstra
---
http://www.radialmind.org
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> Great! Can you please sign-off the patch so that I can apply it?
>
> See here: http://www.zeromq.org/docs:contributing#toc6
>
> Martin
>
From a71f3ce4d8d40bdb7eb8b27495938bcb2a4755f2 Mon Sep 17 00:00:00 2001
From: Gerard Toonstra
Date: Thu, 13 Jan 2011 14:58:49 +0
; between socket object and session object (i.e. creating a pipe in the
> opposite direction). Can you extract that part from your patch and provide
> it as a stand-alone patch?
>
> Once it's applied and tested we can proceed with subsequent steps.
>
> Martin
>
--
Gerard
Hi all,
This is the most current patch for the publisher side filtering.
Note that any devices that are in the middle of a pub/sub route (those
implementing xsub/xpub) should
keep track of subscriptions over all connections they control. So they
should count the number of subscription
requests. W
ssage received events
> (the
> ones that filter on 0 = unsub / 1 = sub) don't filter out normal messages?
>
> Cheers,
>
> James
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/
Does each forked child have its own context?
See the manual, http://zguide.zeromq.org/chapter:all, where it says:
"Getting the context right" :
*If you're using the fork() system call, each process needs its own context*.
G>
On Wed, Dec 8, 2010 at 11:14 AM, Mahadevan R wrote:
> Hi guys,
>
>
27;s XPUB and XSUB in the master. They behave exactly the same
> as PUB and SUB at the moment.
>
> Martin
>
--
Gerard Toonstra
---
http://www.radialmind.org
//
//
#include
#include
#include
#include
#include "zhelpers.h"
int main (int argc,
Hi Martin,
Shortening the mail a bit in this process, comments inline...
On Fri, Dec 3, 2010 at 6:03 PM, Martin Sustrik wrote:
>
>> And then in the "connect_session_t" add calls to
>> "socket-base->socket_connected/disconnected", so that socket-base
>> derivations can
>> be notified of changes
s from topic A.
2. SUB x subscribes to topic A.
3. PUB daemon requests data to be published on topic A.
4. PUB socket processes subscriptions, finds unsubscribe.
5. PUB socket unsubscribes from topic A.
6. PUB socket writes data on A to all channels subscribed.
7. SUB x does not get data
8. On the next bit of data, the SUB x subscribe is found, the list is
updated again.
9. End result: one message is lost and extra bit of overhead of processing
subscriptions for every message published.
is there a better way to start executing code when data is ready to be read
by fq_t?
Rgds,
--
Gerard Toonstra
---
http://www.radialmind.org
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
I've been working on this again yesterday and attached is a draft approach
that works, but has some serious issues to be addressed.
So this should be regarded a draft, intended to receive comments on the
approach taken. The following issues are to be addressed:
1. I've now used the "fair-queue"
Hi Martin,
On Fri, Oct 29, 2010 at 7:00 PM, Martin Sustrik wrote:
> Hi Gerard,
>
> 1. Existing code must not break because of changes ( the default
>> initialization reflects how people use it today ). This means default it
>> does not use filtering at all.
>>
>
> There's filtering there even to
erface of some sort, so that new /
different implementations of "a" filter can be done in the future and where
for example
sockopts are used to choose the filter in use and configure it
accordingly?
Ok, so this is the draft proposal. Let me know wha
mq_socket?
>
> andrew
>
> --
> Andrew Hume (best -> Telework) +1 623-551-2845
> and...@research.att.com (Work) +1 none currently
> AT&T Labs - Research; member of USENIX and LOPSA
>
--
Gerard Toonstra
---
http://www.radialmind.org
_
Conceptually, to some degree, they are similar.
Multicast addressing operates at the level of the IP protocol and is
implemented in routers.
Publisher forwarding is done at the level of the application/platform.
Differences are that managing subscriptions at the IP level is probably much
harder
On Sat, Oct 23, 2010 at 6:44 PM, Martin Sustrik wrote:
> Hi Gerard,
>
>>
>> I've read the mails about publisher side filtering here:
>>
>> http://thread.gmane.org/gmane.network.zeromq.devel/3560
>>
>> - Is there now a current ongoing effort to put publisher-side filtering in
>> 0MQ that I may pos
used to actually carry the data messages. The application / broker
memory
then maintains a subscription registry for each connected client and this
way knows what the subscriptions are.
Comments and advice is very welcome!
--
Gerard Toonstra
___
zeromq
st other
> players in the market where the stakes are literally millions (or billions)
> of dollars. I doubt anyone will give you any hints for free. :-P
> >
> > This sounds like a perfect opportunity for iMatix's professional
> services.
> >
> > cr
>
--
Ger
28 matches
Mail list logo
