IRC Log


Monday January 31, 2011

[Time] NameMessage
[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?