IRC Log


Monday March 14, 2011

[Time] NameMessage
[00:06] travlr Zed's Presentation -- PyCon 2011: Advanced Network Architectures With ZeroMQ : http://blip.tv/file/4878885
[00:07] Guthur decent presentation, a bit lightning fast though
[00:07] travlr ahh, i now see guido_g beat me to the link.
[00:07] travlr Guthur: yeah i'm watching it now
[00:08] Guthur pieterh sent it on the mailing list
[00:08] travlr credit to pieter then. ;)
[00:19] Guthur ah it's not blocking, question from before, just printf was not showing
[01:16] gholt I can't beleive he only got 30mins for 0mq. 0mq does run length encoding?
[04:02] cleifer kind of random question, but if i'm using a pub/sub style interaction and want to "flush" the queue of messages waiting to be published, is there a good way?
[06:11] CIA-103 zeromq2: 03Martin Sustrik 07master * r2970d6c 10/ src/pgm_socket.cpp :
[06:11] CIA-103 zeromq2: Remove obsolete assert from pgm_socket.cpp
[06:11] CIA-103 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/eTHjYC
[06:19] sustrik mikko: hi, are you there by chance?
[06:46] sustrik hi
[06:56] sustrik dermoth: is pipe different from a socket pair in this respect?
[06:58] sustrik the nice thing at least is that pipe is unidirectional rather than bidrectional
[06:59] sustrik meaning it will consume less buffer memory
[07:01] sustrik yep
[07:01] sustrik i recall reading the same about socketpair
[07:02] sustrik cannot find that now though
[07:02] sustrik anyway, i can try using pipes
[07:02] sustrik however, it's likely to break on some OSes
[07:03] sustrik so i would postpone the experiment till stable 2.1 is out
[07:03] sustrik hm, can you set SNDBUF on a pipe?
[07:53] pieterh g'morning
[07:54] guido_g morning
[07:54] pieterh random poll to 0MQ users here: does anyone use the devices packaged with the library?
[07:59] pieterh {poll timeout: ENORESPONSE}
[08:01] guido_g pieterh: saw the guide ch4 checkins yesterday, when will the online version of the be updated?
[08:02] pieterh guido_g: was going to do that now in fact
[08:02] pieterh am just reviewing the text once again
[08:02] guido_g ok, won't disturb you then ,)
[08:02] pieterh np, let me launch it then...
[08:03] guido_g no hurry, page set to auto-reload
[08:06] mikko sustrik: i am now
[08:10] sustrik mikko: the bsd bug
[08:10] sustrik if i send you a patch can you check it?
[08:10] mikko sustrik: sure
[08:10] sustrik ok
[08:10] mikko the pgm type punned pointer?
[08:10] mikko pgm_receiver.cpp:154: warning: dereferencing type-punned pointer will break strict-aliasing rules
[08:10] mikko this one?
[08:12] sustrik yes
[08:13] sustrik sent
[08:17] mikko will test later today!
[08:25] pieterh mikko: when the openpgm integration is stable, can you send a patch to the ML?
[08:28] sustrik pieterh: is there any particular reason why you want to drop devices in 2.1?
[08:28] pieterh sustrik: I'm not dropping devices, just those undocumented, unmaintained examples
[08:29] pieterh 0MQ core should not have these, period
[08:29] pieterh I'
[08:29] pieterh I've been asking for this cleanup since September and each time it's been refused for... no good reason
[08:29] sustrik it's more work to do and you risk annoying users
[08:29] pieterh nope
[08:29] pieterh I've asked now several times if anyone uses these
[08:29] sustrik and it's going to be removed from master once 2.1 is out anyway
[08:30] sustrik so you would have to reconcile both patches afterwards
[08:30] pieterh I want 2.1 to be clean
[08:30] sustrik sure, i don't care
[08:30] pieterh currently it has junk in it
[08:30] pieterh undocumented, bleh :-/
[08:30] pieterh these should have gone ages ago
[08:30] pieterh also I've restored the zmq_device(3) man page which seems essential
[08:30] pieterh lastly, having these devices in there gives them special weight they do not deserve
[08:31] pieterh and which contradicts developing *real* apps elsewhere
[08:31] pieterh finally, they are unmaintained
[08:31] pieterh and have survived several attempts at improvement
[08:31] pieterh which is inexcusable
[08:31] sustrik well, i would say that 2.1 should be called something else than stable then
[08:31] pieterh when unused code resists improvement, it has to be killed
[08:31] sustrik what about "iMatix enterprise distribution"?
[08:31] pieterh "stable and clean" if you prefer
[08:32] pieterh you focus on making the core, I'll take responsibility for clean packages, ok?
[08:32] sustrik sure
[08:32] pieterh thanks
[08:32] pieterh I note that both Jon Dyte and myself contributed documented, cleaned up improvements to those devices
[08:33] pieterh both times, rejected for no good reason
[08:33] pieterh this annoys me to a point you perhaps can't appreciate
[08:33] sustrik they are scheduled for removeal
[08:33] sustrik freezed
[08:33] pieterh bogus argument
[08:33] pieterh for the last 6 months?
[08:33] sustrik yes
[08:33] sustrik till 3.0
[08:33] pieterh lol
[08:33] pieterh I'm not even going to argue this
[08:34] pieterh you want a distribution with rubbish in it, make it
[08:34] sustrik well, if you want a stable stable you have to maintain it for 5+ years
[08:34] sustrik backward compatible
[08:34] pieterh I'm not interested in releasing crap
[08:34] pieterh no excuses
[08:34] pieterh and everything in the distribution must be maintained or documented, or removed
[08:34] sustrik maintaining crap is what "stable" means
[08:34] pieterh no excuses
[08:34] sustrik otherwise you are doing dev branch
[08:35] sustrik anyway, it's up to you
[08:35] pieterh no Martin, and with all due respect, maintaining releases over years is something I'm expert in, whereas you are not
[08:35] sustrik i don't really care
[08:36] pieterh then don't argue with me
[08:36] sustrik do it as you believe it's best
[08:36] pieterh I always do
[08:36] sustrik just warning you
[08:36] pieterh and I'm intensely interested in the opinions of real users
[08:36] pieterh but not interested in discussing "policies" that are unhelpful and arbitrary in this case
[08:40] pieterh again, if *anyone* here is actually using these device apps, please speak up
[08:41] pieterh I'll ask again on the ML before taking a final decision
[08:41] pieterh mikko: there's been some changes to the Wikidot API, so it broke
[08:42] pieterh if you're generating the api.zeromq.org it'll have stopped working
[08:54] guido_g pieterh: fig62.png seems to be missing
[08:54] pieterh guido_g: thanks, let me fix that
[08:55] guido_g and a feature request: is it possible to fold the code listings like the toc?
[08:56] pieterh guido_g: yes, it's a good idea
[08:56] pieterh I'm redesigning the whole code listing UI, will do this as part of that
[08:56] guido_g they're simply too large for the main text now
[08:56] pieterh yup, monsterous :-)
[08:56] guido_g great! thanks in advance
[08:58] pieterh guido_g: ok, the images should all be working now, may need a reload
[08:58] guido_g works now
[08:58] Guthur +1 for code folding
[08:58] guido_g :)
[09:21] Guthur pieterh: 5 specifications within 13 days, that's quite a feat
[11:28] pieterh Guthur: ... am in meetings all day...
[11:28] pieterh making specifications is kind of a hobby of mine
[11:28] pieterh I think it's time to properly document the 0MQ wire protocols, all of them
[11:28] pieterh dermoth|home: do you use the code from the repository or have you made your own versions?
[11:30] Guthur +1 on 0MQ wire protocols
[11:30] Guthur better to get it done sooner rather than later in imo
[12:24] Guthur is there a minimum language version requirement for the python or perl binding
[12:24] private_meta Is the lack of a dedicated zmq::version call intended?
[12:25] Guthur also, how is 0MQ on solaris?
[12:57] Guthur re My solaris question; I notice the daily build is on solaris 10, anyone know if 0MQ is working on solaris 8
[13:00] Steve-o I wouldn't expect much unless you try G++
[13:03] Steve-o Wasn't it EOL a while ago?
[13:04] Steve-o Forte might be too old, but I think at least one of the Sun ONE Studio's runs on 8?
[13:05] Guthur Steve-o: Yeah we need to move soon
[13:05] private_meta pieterh: I know it's just a wrapper, but for uniformity it would be nice to have the zmq::version call in the C++ version
[13:05] Guthur I wish we could easily migrate to RH
[13:05] Guthur that's an option, but probably a painful one
[13:07] Steve-o Guthur: you actually using Solaris on x86/x64?
[13:09] Steve-o it's bad enough that studio 12 is still out-of-date, Google Protobufs doesn't work well with Sun's STL stack
[15:15] jstrom hm i sent an email to zeromq-dev a few hours ago, haven't showed up in archives yet.. any problems with mail delivery/bad spam detection?
[15:15] jstrom or is there moderation?
[15:24] private_meta jstrom: The last time I sent an email it showed up immediately, so I doubt there is moderation
[15:25] jstrom okey, wierd
[15:25] private_meta jstrom: and,I see an email by you in my mailbox
[15:25] jstrom Just signed up but that usually doenst make any difference in mailman..
[15:25] jstrom oh, okey
[15:25] private_meta depending on your time zone, 1[1|2]:36
[15:25] jstrom Guess its just the archive beeing slow then :) I opted for digest mail, so I didnt get the mail myself directly
[15:25] jstrom yep
[15:27] private_meta By the way, it's in the archive as well
[15:28] private_meta jstrom: I have no idea why, but apparently your mail, if sorted by Topic, was considered as a reply to "[zeromq-dev] Poll about linger and termination behaviour!"
[15:29] jstrom hah.. yeah, there I see it.. thats very wierd indeed.. the gmane archive has it correct though: http://news.gmane.org/gmane.network.zeromq.devel
[16:34] troutwine Aside from tunneling, what are my options for secure transmission? SSL is not natively supported, right?
[16:42] cremes troutwine: there are no built-in options for security
[16:42] cremes tunneling is probably the easiest solution at this point
[16:42] troutwine cremes: Tunneling is out of the question, sadly.
[16:42] cremes you might want to search the mailing list archives for this question; it has come up a few times
[16:43] cremes and there might be a solution for you listed there
[16:43] troutwine cremes: I did, but didn't find anything terribly promising.
[16:43] cremes too bad... perhaps you could try asking again and describe your use-case
[16:43] cremes maybe someone has come up with a clever solution and is waiting for someone to ask about it before sharing :)
[16:44] troutwine cremes: Maybe. Thanks.
[16:44] nadime it wouldn't be terribly hard to write your own ZMQ-SSL wrapper
[16:44] nadime someone may have done so, and just not released it
[16:45] nadime cremes -- question for you
[16:45] cremes nadime: shoot
[16:46] troutwine nadime: I think that's what I'm going to do, but I know squat about SSL implementations, or really about ZMQ internals. Any pointers?
[16:47] nadime i don't think you need to know anything about zmq internals
[16:47] nadime but you do need to look at a few SSL implementations probably
[16:47] nadime you basically want to create a message class where you're encrypting the dataload
[16:47] nadime you can do something much simpler than a full implementation
[16:47] cremes i recommend looking at this UML diagram for a "taste" of the 0mq internals
[16:47] cremes https://github.com/thijsterlouw/zeromq2-uml
[16:48] nadime cremes - for high I/O throughput scenarios, is it basically recommended to have 1 input and 1 output thread (or N input/output) to avoid using a poller?
[16:48] nadime the zmq implementation of poll seems incredibly slow, it was what was causing my i/o bottleneck yesterday
[16:50] nadime troutwine -- how scalable do you need your solution to be?
[16:51] nadime cremes - sorry, that was unclear. i'm asking -- is it recommended to never use zmq_poll for high throughput
[16:51] troutwine nadime: A few thousand concurrent clients; not terribly.
[16:52] cremes nadime: it's hard to say; are you using zmq_poll with a timeout or do you use it to block?
[16:52] nadime either, both are slow
[16:53] cremes nadime: interesting; i don't think anyone has done any real benchmarks in this area
[16:53] nadime i was running about 500k msgs/s, avg. 50B msgs, so about 25MB
[16:53] nadime and i was falling behind because of a poll (with either block or timeout, tried both)
[16:53] nadime so i was pushing 500k until i hit the poll, then only getting about 100k/s
[16:53] cremes you only had a handful of sockets, right? like 4 or 5 of them?
[16:53] nadime and my app was blowing up because of the buffering
[16:53] nadime yep
[16:54] cremes wow, that's terrible
[16:54] nadime the memcpy was killing me
[16:54] cremes any chance you could open an issue illustrating this problem?
[16:54] nadime i'm on win7, so i think zmq_poll uses select()
[16:54] cremes ah... windows
[16:54] nadime sure in a day or two, i can probably make an example case pretty quickly
[16:55] cremes windows has probably gotten the least attention out of all of the platforms
[16:55] troutwine nadime: Limited by human latency, I'd guess each client is going to push one message a half-second. So a few thousand sockets, 4,000 msgs/s.
[16:55] troutwine nadime: Why do you ask?
[16:55] cremes the 0mq project doesn't have a lot of windows-savvy devs working on it yet; there are a few but progress is slow
[16:55] nadime worried about key exchange, troutwine
[16:55] nadime not throughput
[16:56] nadime you should basically look up how SSL handles key exchange, once you have keys on both sides, it's really easy to use ZMQ to do secure xfer
[16:56] cremes nadime: you might want to ping Guthur and ask him about his work on using windows-native-api poll stuff
[16:56] troutwine nadime: I'm reading up on SSL now. Clearly I know nothing about it.
[16:57] nadime thanks, i will do that
[16:57] nadime i was planning on taking a look at the implementation when i have a sec, gotta finish this project though
[16:57] nadime but if he's already working on it, maybe we can team up
[16:57] cremes nadime: good idea; i'm sure he would appreciate a hand
[16:58] cremes nadime: his focus is on getting ipc transport working on windows
[16:58] cremes but that stuff is all tied in with polling for events and handling i/o completion
[16:58] nadime ah, well i don't care about that, but happy to help re: poll implementation ;)
[16:58] cremes i think a solution for both pretty much go hand in hand
[16:58] nadime gotcha
[16:59] cremes based on what Guthur was posting here last week and the week before
[16:59] nadime he wants to do ipc using files?
[16:59] nadime and the windows poll implementationc an't handle sockets and files?
[16:59] cremes nadime: it's best just to ask him; he can explain it with the minimum amount of confusion (that i might add if i try)
[17:00] nadime k
[17:00] Guthur did I hear my name, hehe
[17:00] cremes Guthur: you did!
[17:00] nadime you did -- cremes was just asking me to ping you about your work on windows zmq_poll implementation
[17:01] cremes nadime has noticed that zmq_poll() sucks donkey on windows
[17:01] Guthur it's a 'feature'
[17:01] Guthur windows comes with extra donkeys for just such cases
[17:01] nadime haha
[17:02] Guthur but yeah, we really need to look at getting IOCP
[17:02] Guthur or possibly, at the very least, WSA_POLL (I think thats the name)
[17:02] nadime what is zmq_poll implemented using right now? select()?
[17:02] Guthur IOCP would be the bigger win because it would give IPC
[17:03] Guthur nadime: I believe so
[17:03] Guthur It only does TCP though
[17:03] Guthur Select doesn't support named pipes unfortunately
[17:03] cremes nadime, Guthur: i'll leave you two windows experts to hash things out :)
[17:03] nadime and i take it wsa_poll doesn't either
[17:04] Guthur nadime: As far as I am aware, nope
[17:05] nadime IOPC looks pretty nifty
[17:05] Guthur I think the only realistic option for named pipes is IOCP or WaitForMultipleObjects
[17:05] nadime would eliminate the need to memcpy the fd list for in, out, err every cycle which is i think what slows down the poller on high throughput
[17:05] Guthur IOCP is pretty sweet
[17:06] Guthur but it doesn't naturally fit into the 0MQ engine as is, afaik
[17:07] Guthur it will require an abstraction layer over named pipes and IOCP
[17:07] Guthur I think it's due to the fact that 0MQ needs some state reflection which IOCP doesn't cover, sustrik is the man to talk to for 0MQs needs though
[17:07] nadime it looks like it will actually need to loop over all requested sockets/pipes instead of operating like select()
[17:08] nadime nm
[17:08] Guthur sorry I need to go, but i'll be back in an hour or so
[17:18] private_meta github is amazingly stupid
[17:18] private_meta my account doesn't work, I can't log in
[17:18] private_meta they're sending me to the support page
[17:18] private_meta which you can only access when you're logged in
[17:20] michelp morning/afternoon/evening everybody
[17:21] private_meta pieterh: If you don't mind adding that in a future release, add this to zmq.hpp: https://gist.github.com/94ced4a644021248f4d7 <- just for unifying the c++ binding and for not having to use C calls
[17:22] private_meta pieterh: I don't want to clone the entire thing just to get a patch for that if you don't mind
[17:22] guido_g you know how to submit patches
[17:22] guido_g there is *a lot* of information missing
[17:23] private_meta Ok, then leave it out
[17:44] pieterh re
[17:44] pieterh sorry, am in meetings all day
[17:44] pieterh private_meta: patches need to follow contribution policy
[17:45] private_meta So i need to go through all that (imho annoying) stuff to see a 1 line method in there?
[17:45] pieterh private_meta: wrt to github are you trying to login with an organization id?
[17:45] pieterh private_meta: yes, even for a 1-line patch, sorry
[17:45] pieterh well, perhaps I can make the change, hang on...
[17:47] private_meta Working on zguid I'm doing multiple changes, and I understand that a patch is necessary
[17:47] pieterh private_meta: I'll make that change myself, and send a patch to martin, tomorrow
[17:47] private_meta a *patch
[17:47] pieterh i'll get all the credit for it, be warned
[17:47] pieterh :-)
[17:47] private_meta sure, I don't need the credit anyway
[17:48] pieterh it's kind of a joke, credit for a 1-line method
[17:48] private_meta ik
[17:48] private_meta I mean creadit there in general
[17:48] private_meta *credit
[17:48] pieterh it's more about blame than credit
[17:48] pieterh ok, have to flee, cyl
[17:48] private_meta thanks
[18:10] nadime anyone know: what's the behavior of the io threads f you set socket affinities to threads out of range, e.g. you have 1 io thread but you set a socket's affinity to 8
[18:45] loxs hi folks, jus saw Zed's talk on 0mq at PyCon and there I saw him saying it's not a good idea to put it on the internet...
[18:45] loxs uhm, it kind looks really promising for things like game networking
[18:46] loxs so, are there any plans to make suitable to work on the internet?
[18:50] loxs Zed said "they are working on it", but what does this mean?
[18:53] cremes loxs: you need to remember the context in which zed said that
[18:53] cremes he likes to 'fuzz' all of his projects (send random data to them)
[18:54] cremes he noted that 0mq still has assertions that will trigger when bad data is received on the port
[18:54] cremes so a perfect DOS attack would be to send random data to a 0mq socket and crash the lib
[18:54] cremes the 0mq guys are 'working on it' in the sense that they are slowly but surely removing those assertions
[18:54] cremes and fixing the library's behavior in the face of bad data
[19:01] michelp if you can handle the overhead of it openvpn might be a good solution to securing a 0mq network over the internet
[19:02] michelp i hear some game networks are using it successfully
[19:02] michelp it also lets you do things like revoke access to rogue clients
[19:04] cremes zed's talk was only "okay"; due to time pressures he touched so lightly on 85% of the important stuff
[19:04] cremes that unless you were already a 0mq practitioner i doubt the audience got much out of it
[19:06] loxs well, I didn't, but the idea of "one messaging system to rull them all" started some bells in my head :)
[19:07] loxs michelp, well, it's not an option if you don't trust the client (if it's a game, people will try to do all kinds of hacks to cheat the game)
[19:07] loxs michelp, which game networks use zeromq?
[19:09] michelp loxs, i don't know, just something i read while i was cruising through google setting up my own private vpn
[19:12] mikko sustrik: tested and works
[19:16] michelp loxs, sorry i misread your question, i meant some game networks are using openvpn, not 0mq
[19:16] michelp based on what i read only, not on any direct knowledge
[19:17] michelp my suggestion was that if you were going to use 0mq over the internet, using it on a vpn might be a good approach to avoid fuzz hacks on an open port
[19:18] loxs I see. Yep, you are right
[19:19] loxs but it would be really cool if you could use zeromq directly for client server communication
[19:19] sustrik mikko: thx
[19:30] CIA-103 zeromq2: 03Martin Sustrik 07master * rf987f4b 10/ src/pgm_receiver.cpp :
[19:30] CIA-103 zeromq2: FreeBSD complation error fixed
[19:30] CIA-103 zeromq2: There was an error in pgm_receiver wrt strict aliasing.
[19:30] CIA-103 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/ecz5VG
[19:34] andrewvc cremes: around?
[19:37] cremes andrewvc: for about 20m
[19:38] andrewvc a couple things
[19:38] andrewvc 1: you know the deal with all the finalizer errors on the specs
[19:38] andrewvc also, I added a zdevice branch to ffi-rzmq with a new ZMQ::Device class
[19:39] mikko sustrik: i'm confused
[19:39] mikko sustrik: do fixes go first to zeromq2 or zeromq2-1 repo?
[19:46] cremes andrewvc: i'll take a look at the zdevice branch tonight/tomorrow and give you feedback if anything pops
[19:46] andrewvc cool
[19:46] cremes however, i'm not sure what you mean about finalizer errors; i'm not getting any
[19:47] cremes can you pastie the errors you see? (i might have fixed 'em and forgot to push them)
[19:47] andrewvc sure
[19:47] andrewvc one sec
[19:51] andrewvc cremes: https://gist.github.com/869738
[19:51] andrewvc actually, there's a variety of errors
[19:51] andrewvc that's on rbx
[19:52] cremes huh
[19:52] cremes i don't get those under mri; i'll try under rbx and get them patched up
[19:52] cremes looks like we found another hole in rbx's ffi support
[19:57] andrewvc interesting
[19:59] sustrik mikko: i'm maintaining master (zeromq2)
[20:00] sustrik pieter volunteered to do stable releases
[20:01] sustrik so he should decide on the process for zeromq2-1
[20:02] mikko sustrik: so they should be treated as separate projects?
[20:04] sustrik you should ask pieter
[20:05] sustrik my understanding of stable is maintaining the backward compatibility while backporting patches
[20:05] mikko i shall ask him when we meet
[20:05] sustrik ok
[20:07] mikko sustrik: where is subscription forwarding going on?
[20:07] mikko is it stable?
[20:07] sustrik mikko: it's still on a branch
[20:07] sustrik not finished yet
[20:07] mikko ok
[20:07] sustrik then it'll go to master obviously
[20:08] sustrik not sure about stables
[20:08] mikko it crossed my mind yesterday
[20:08] mikko was writing a small utility that uses pub/sub sockets
[20:08] mikko so, next i need to get pieterh to merge the freebsd pgm build fix
[20:08] mikko and test steve's upstream changes
[20:08] sustrik he'll do i so, i think
[20:09] sustrik ack
[23:42] Guthur any suggestions on why i might get a phantom POLLIN event
[23:44] Guthur oh wait nvm, something more fundamentally wrong with my code
[23:47] Guthur yep I was being a silly programmer