[Time] Name | Message |
[01:56] traviscline
|
ANN: cythoneriffic version of gevent-zeromq pushed
|
[02:18] monokrome
|
Has anyone ran in to issues where this assertial fails unpredictably in the middle of a request/reply loop using ZMQ_REQ and ZMQ_REP? https://github.com/zeromq/zeromq2/blob/master/src/tcp_socket.cpp#L92
|
[02:20] monokrome
|
Seems to be occuring due to recv()
|
[02:21] monokrome
|
s/assertial/assertion/
|
[07:34] pavimus
|
Hi everybody!
|
[08:04] monokrome
|
Is zeromq good for extremely low-latency networking?
|
[08:31] sustrik
|
andrewvc: why do you need ipv6?
|
[08:32] sustrik
|
its something that would be nice to get functioning
|
[08:32] sustrik
|
but nobody seemed really interested in it so far
|
[08:33] sustrik
|
monokrome: can you find out what the actual error is?
|
[08:34] sustrik
|
monokrome: yes, it should be good for low latency
|
[08:34] sustrik
|
of course, depending on what you mean by low latency :)
|
[09:07] monokrome
|
Multiplayer gaming
|
[09:10] sustrik
|
ah
|
[09:10] sustrik
|
that's not really low latency
|
[09:10] sustrik
|
it should be OK
|
[09:10] monokrome
|
It's preferably as low as possible :)
|
[09:12] sustrik
|
i mean, you don't care about nanoseconds, do you?
|
[09:12] sustrik
|
it's not like supercomputing
|
[09:17] monokrome
|
No
|
[09:18] monokrome
|
But you can't get a message across the world in nanoseconds anyway :)
|
[09:23] sustrik
|
exactly
|
[09:24] sustrik
|
so 0mq should be ok for you
|
[09:24] sustrik
|
what it adds to overall latency can be measured in order of microseconds
|
[09:24] monokrome
|
ok
|
[09:25] monokrome
|
and it probably takes care of things faster than I'd write it anyway :)
|
[09:25] monokrome
|
thanks
|
[09:25] sustrik
|
monokrome: can you have a look at the error you've reported?
|
[09:26] sustrik
|
if you let me know what the error is i can fix the problem promptly
|
[09:31] monokrome
|
sustrik: I'm not sure what it was, but it was on tcp_socket.cpp:92
|
[09:31] sustrik
|
can you check out the error code?
|
[09:32] monokrome
|
We relieved the error from switching from a Poller to ZMQ_NOBLOCK
|
[09:32] sustrik
|
can you reproduce it?
|
[09:33] monokrome
|
There was no error code. It is an assertion checking that the size of a result wasn't SOCKET_ERROR
|
[09:33] monokrome
|
I can not reproduce this easily
|
[09:33] monokrome
|
However, it happened with a simple client passing data as a protocol buffer with a string prefix to a server and the server passing it back. It occured during the client call to recv
|
[09:34] monokrome
|
I was using PyZMQ, so it could have occured due to their code also.
|
[09:34] monokrome
|
I'm not sure how Poller works, so I change my coworkers code to use ZMQ_NOBLOCK and it was fixed.
|
[09:34] monokrome
|
The poller was also causing a very large drop in frames per second
|
[09:35] sustrik
|
what you can do is add printf() to tcp_socket.cpp
|
[09:35] sustrik
|
to print out the error number
|
[09:35] monokrome
|
Well, this was a while ago and ZMQ_NOBLOCK fixed the issue
|
[09:36] sustrik
|
pitty
|
[09:36] monokrome
|
Albeit, I think poller might be more efficient
|
[09:36] sustrik
|
it would be good to fix the problem
|
[09:36] monokrome
|
Yeah.
|
[09:36] monokrome
|
Anyway, I will try and reproduce it tomororw.
|
[09:36] monokrome
|
I am going to bed
|
[09:36] monokrome
|
nite :)
|
[09:37] sustrik
|
hello
|
[09:38] sustrik
|
that's a deadlock, right?
|
[09:40] sustrik
|
we've seen an issue with massive reconnections
|
[09:41] sustrik
|
the problem is there's a lot of handshaking between application and OS threads then
|
[09:42] sustrik
|
the commands are passed via a socketpair, which fills up and causes a deadlock
|
[09:42] sustrik
|
so what you can do is to increase the socketpair buffer size
|
[09:42] sustrik
|
is that linux?
|
[09:43] sustrik
|
check the email from dhammika pathirana on the mailing list today
|
[09:43] sustrik
|
he explains how to do that
|
[09:43] sustrik
|
the real solution is in 2.1 though
|
[09:43] sustrik
|
the buffers are increased gradually when they are filled up
|
[09:54] sustrik
|
more or less stable
|
[10:12] dermoth
|
Sustrik, i'm out now... but if there's a way to crash (i.e. assert) the device when that happens that will be a good fix for me. it turns out reliability was already quite good when our devices restarted every 5 seconds exceeding the max file limit :). You could maybe reply to my post if there's a way. Thanks!
|
[10:13] sustrik
|
dermoth_: sure, ping me when you are back
|
[10:13] sustrik
|
i'll explain
|
[11:00] monokrome
|
Hmm... Is there a way to get the C++ bindings to not throw exceptions?
|
[11:05] jugg
|
http://www.google.com/search?q=zeromq+c%2B%2B+nothrow
|
[11:05] monokrome
|
Thank you, jugg. I tried searching around before this, but didn't use the "
|
[11:05] monokrome
|
nothrow" keyword
|
[11:06] monokrome
|
ah, using the C API was my solution anyway
|
[11:06] monokrome
|
I guess it was the right one :)
|
[11:06] jugg
|
:)
|
[11:07] monokrome
|
Thanks for your confirmation
|
[12:18] stimpie
|
Does the pub-sub pattern imply that all data is send to all subscribers and the subscriber filters the messages?
|
[12:58] stockMQ
|
Hi..anyone using protobuf with zmq C++
|
[12:59] stockMQ
|
I am facing some issues regarding serializing to and parsing from
|
[13:01] stockMQ
|
I would like to know what is the right way to serialize a protobuf message to zmq_message
|
[13:01] stockMQ
|
when i do
|
[13:01] stockMQ
|
pkt = new std::string();
|
[13:02] stockMQ
|
feedPacket->SerializeToString(pkt);
|
[13:02] stockMQ
|
s_send (*this->publisher,pkt->c_str());
|
[13:02] stockMQ
|
Protobuf throws fatal exception at SerializeToString
|
[13:05] stockMQ
|
just found this http://msgsys.googlecode.com/svn-history/r22/trunk/doxygen/group__serialization.html
|
[13:49] stockMQ
|
again same issue
|
[13:49] stockMQ
|
it happens in void LogMessage::Finish() of common.cc
|
[20:00] mikko
|
Steve-o: there?
|
[21:35] mikko
|
Steve-o: i got it working a over weekend
|
[21:35] mikko
|
Steve-o: but there is a minor problem
|
[21:53] fredfoo
|
Does anyone know of real world examples using 0mq?
|
[21:57] mikko
|
fredfoo: yes
|
[21:57] mikko
|
fredfoo: mongrel2 webserver is a good example
|
[22:33] Steve-o
|
mikko: in the logs? just back from shopping in CT.
|
[22:35] Steve-o
|
mikko: the last build looks a tad small, 144KB compared to 560KB before ?
|
[23:50] Steve-o
|
mikko: you need the pdb file?
|