[Time] Name | Message |
[00:26] jcase
|
Any clue as to what I might be doing wrong when I get an Assertion failed: ok (mailbox.cpp:79)? Using multiple PUB/SUBs over a forwarder device. v2.1.9
|
[00:43] mikko
|
jcase_: where does it happen?
|
[00:50] jcase
|
PUB connecting to the SUB frontend. Looks like its a threading issue though. If I run the thread in the foreground it works fine
|
[00:59] mikko
|
jcase_: are you using the socket(s) from multiple threads?
|
[01:05] jcase
|
mikko: ye, socket is created outside a thread and then used from within. Now I create the socket within the thread and pass it as an argument which is working fine. So, it's just me failing at (python's) threading :)
|
[01:11] mikko
|
sustrik: the updated patch is in jira
|
[11:25] mikko
|
sustrik: hi
|
[11:55] sustrik
|
mikko: hi
|
[14:00] mikko
|
sustrik: with the latest patch i get the desired behaviour
|
[14:00] mikko
|
but i am still trying to understand why
|
[14:26] sustrik
|
mikko: why what?
|
[14:34] mikko
|
sustrik: why it works
|
[14:34] mikko
|
does the pipe try to read again on EAGAIN?
|
[14:35] sustrik
|
not the pipe
|
[14:35] sustrik
|
there's a loop in socket_base_t
|
[14:36] sustrik
|
in a blocking call it loops till it gets a message
|
[14:36] mikko
|
ok
|
[14:36] mikko
|
so the fix for the assertion is pretty contained to req.cpp
|
[14:36] mikko
|
just returning EAGAIN for now
|
[14:36] mikko
|
well, errno EAGAIN
|
[14:36] sustrik
|
right
|
[14:38] mikko
|
nice
|
[15:49] mikko
|
sustrik: are you happy with the patch as it is?
|
[15:50] sustrik
|
yep, i would do it the same way
|
[15:50] sustrik
|
thanks for adding the test cases as well
|
[15:51] mikko
|
it's better for regressions that way
|
[15:51] mikko
|
i'll start slowly tackling these assertions
|
[15:51] mikko
|
i find them slightly problematic in some cases
|
[15:51] sustrik
|
great
|
[15:52] sustrik
|
some of there are pretty low hanging fruit afair
|
[15:52] sustrik
|
some are more problematic
|
[15:52] sustrik
|
like running out of memory of file descriptros
|
[21:35] muhgatus
|
Hi :)
|
[21:39] muhgatus
|
I have a in normal cases simple question, but within a zeromq network it seems a little bit hard to implement. how do i limit access to this zeromq network? the simplest way i could imagine is to limit the ipaddresses that are allowed to connect to my sockets, but this seems not to be the right way when i wish to use 0mq.
|
[21:41] mikko
|
muhgatus: what do you want to restrict?
|
[21:41] mikko
|
peers from connecting or peers from seeing your messages?
|
[21:41] mikko
|
is this a pub/sub?
|
[21:44] muhgatus
|
mikko, i think i do not want unknown peers to send messages into the network.
|
[21:47] muhgatus
|
it is not pub/sub only. i little bit more complex i guess. i am trying to rewrite an irc/minecraft/webchat bot by using 0mq. so, there will be pub/sub but not exclusivly.
|
[21:49] muhgatus
|
the bot connects an irc channel with a minecraft server and a webchat. its used to transport the messages from irc to the minecraft server and also to the webchat.
|
[21:50] muhgatus
|
there are some inner restrictions, as not all users talking to the irc interface can access all features of the bot.
|
[21:50] muhgatus
|
i hope, this gives you a idea of what i am planing to implement.
|
[21:52] muhgatus
|
my problem is, that all parts of the bot run in different contexts on different hosts. currently i use http to connect these parts, but this "middleware" is hard to maintain :)
|
[22:15] mikko
|
muhgatus: maybe pki
|
[22:16] mikko
|
ahmm
|
[22:16] mikko
|
let me read that again
|
[22:16] mikko
|
yes, pki might work as you control all the endpoints
|
[22:20] muhgatus
|
ok, can i drop connections, after i got a wrong message?
|
[22:37] mikko
|
muhgatus: nope
|
[22:37] mikko
|
you can stop routing messages to that peer
|
[22:38] muhgatus
|
but this only works when i use xreq/xrep, right? in a pub/sub this is not possible, i guess.
|
[22:39] muhgatus
|
in a pub/sub the subscriber is able to set up a filter, but all messages are send to that subscriber. am i right? :)
|
[23:01] sustrik
|
muhgatus: that's the case with 0MQ/2.x
|
[23:01] sustrik
|
in v3 the messages are filtered on the sender side
|
[23:06] muhgatus
|
sustrik, ok.
|
[23:07] muhgatus
|
are there regex like filters? so one subscriber can subscribe multiple sorts of messages or has the subscriber to subscribe more than once?
|
[23:25] mikko
|
nope, the built-in filtering is prefix match
|
[23:26] mikko
|
you need to subscribe multiple times or design your topics in a way that you can subscribe to a node of a tree
|
[23:26] mikko
|
let's say topics like: topic.private, topic.stuff, topic.stuff.specifics
|
[23:26] mikko
|
user that subscribes to 'topic.' will receive all
|
[23:27] mikko
|
'topic.stuff.' will receive the two latter
|
[23:27] mikko
|
etc
|
[23:28] muhgatus
|
this does not fit to my categories, but the idea is great. perhaps i am able to build up such prefixes.
|
[23:29] muhgatus
|
in my case its something like public.irc, public.web, public.minecraft, join.irc, join.web, join.minecraft, etc
|
[23:29] muhgatus
|
but this pattern would work.
|
[23:30] muhgatus
|
thank you for your help mikko and sustrik :)
|
[23:30] mikko
|
no problem
|
[23:30] muhgatus
|
i'll come back next sunday with new problems ;)
|