Sunday April 17, 2011

[Time] NameMessage
[07:26] rod Hi, i'm new to 0mq so forgive me if my question has an obvious answer. What i'm trying to do use use a REQ socket to receive a request, then dispatch a job to worker threads which call back when they're done. But it seems with the REQ socket type you need to send a reply before you can receive another request, is this true? if so is there another solution for my problem? Thanks.
[07:27] Toba you have to use REP socket for the server side (the one receiving requests) not a
[07:27] Toba you use REQ on the side making the requests.
[07:27] Toba this may be your first problem :)
[07:28] rod ah yes sorry that's what i meant :D
[07:28] rod (see, i am new to this!)
[07:28] pieterh rod_: it's explained in the Guide
[07:28] Toba I don't know a way to work around this, no.
[07:28] Toba but, the Guide is all knowing, and eternal.
[07:28] pieterh if you want to handle multiple requests in parallel, use a ROUTER socket
[07:29] pieterh aka xrep
[07:29] pieterh there is an example that does exactly what you want, asyncsrv
[07:29] rod ah perfect. ok i'll give that a go, thanks pieterh!
[07:30] pieterh
[07:30] pieterh however, before trying that, please do read & understand chapters 1 and 2
[07:32] rod i've made it to the end of chapter 2 so far, but i'm trying to build some examples to help me learn (so might be jumping ahead too which is the problem here i think)
[08:26] guyvdb Hi, I was listening to a video of Zed Shaw speaking from the zmq site. He stated something along the lines of do not use zmq over the internet. I.e. keep it within your lan for connecting server processes. Is this correct?
[08:26] guido_g ahhh... salt already made it into the wiki
[08:27] guido_g guyvdb_: sure, and you can always use a vpn
[08:28] pieterh guyvdb_: 0MQ sockets tend to crash if you throw garbage at them
[08:29] guyvdb hmm ... I have a bunch of embedded devices that connect via 3G that I want to keep track of. After Zeds comments my idea is asio between well known address (broker) and clients and then zmq in the back to worker processes. Does this make sense?
[08:31] pieterh guyvdb_: asio isn't going to be more secure than 0MQ
[08:32] pieterh well, perhaps it is... yes, this makes sense
[08:32] pieterh if I was doing it over public Internet I'd use HTTP for the server
[08:32] guido_g why?
[08:33] guyvdb hmm I thought of that... but I want allways connected... I.e. server push to client...
[08:33] guido_g i mean http is ok, but not the answer to everything
[08:33] pieterh guido_g: several reasons, but mainly it's friendly for sysadmins (ports 80 and 443), has proven security (TLS), and has stacks in clients
[08:33] pieterh guyvdb_: you can quite easily do server push using long polling
[08:34] guyvdb would http long poll make sense? This seems like a bit of a hack when i could just use tcp with thrift or protocol buffer
[08:34] guido_g long polling and mobiles devices isn't that clever, to get a reasonable reaction time you to wake up the device quite often
[08:34] guyvdb The clients are embedded bits of hardware... no user interface, etc
[08:35] pieterh guyvdb_: http long poll is nothing special, but you may need some intelligence in the server
[08:35] pieterh i.e. to not disconnect clients if they're silent
[08:36] guyvdb but would an ASIO server maintaining say 5000 connections with the clients not be better than long polling
[08:36] pieterh guyvdb_: afaics it's precisely the same setup except that with HTTP you get a standard answer to parts of the problem
[08:36] guido_g and find someone who did that to ask him how the carriers behave in this case
[08:36] guyvdb I also want to implement heartbeat ala AMQP or something like that
[08:37] pieterh you would want a friendly http server
[08:37] guido_g and websockets :)
[08:37] guyvdb any suggestions? mongrel 2? ngnix
[08:37] guyvdb There is no web browser involved
[08:37] guido_g mongrel2 is of course the first choice if you want to use ømq
[08:38] pieterh guyvdb_: I'd suggest mongrel2, yes, mainly because you can probably tweak it if you need it
[08:38] pieterh also, take a look at
[08:38] guido_g guyvdb_: websockets is an hhtp protocol extension, no browser needed
[08:38] guido_g guyvdb_: but is was more of a joke
[08:38] pieterh guyvdb_: do you have security requirements?
[08:39] guyvdb yes.. i want a pki infrastructure where i am CA and all clients must have valid certs
[08:39] pieterh so using https gives you this basically for free
[08:39] guido_g then use a good http kit
[08:39] guyvdb yea... does mongrel2 use openssl?
[08:39] pieterh after that you can use various techniques to switch to a bidirectional async protocol on top of http
[08:40] pieterh guyvdb_: i assume it does
[08:40] guyvdb hmm any insight into a bidirectional async protocol on http... have you seen any implementations / papers / blogs on this?
[08:40] pieterh guyvdb_: the very simplest is to open two connections per client, one for reading, one for writing
[08:41] pieterh reading uses long polling (see restms for some hints)
[08:41] pieterh writing just posts stuff
[08:41] pieterh a more efficient approach is to use the http protocol upgrade method
[08:41] pieterh which lets you start a http session, then switch to your own binary async protocol afterwards
[08:42] pieterh that requires a cooperative http server, obviously
[08:42] guyvdb that sounds promising
[08:42] pieterh i believe there are quite a few such stacks already built
[08:43] pieterh you could look at for inspiration
[08:43] pieterh websockets is meant to standardize this area but it's stuck in endless ietf discussions
[08:44] pieterh an example implementation of bwtp:
[08:45] guyvdb Ok... i think that is a lot for me to absorb right now... going to start with lots of reading :) Thanks pieterh you have been very helpful
[08:45] pieterh guyvdb_: my advice would be to start with a minimal proof of concept using something like restms's transport layer (resttl)
[08:45] pieterh and if you find http works for you, look at more efficient designs
[08:46] pieterh let us know how you get on :)
[08:46] guyvdb will do... thx
[10:25] guido_g i will not implement this!!/hintjens/status/59561500293083136
[10:28] headzone good, we're relying on you to implement zeromq over BLOAT (RFC 3252)
[10:28] headzone that clearly takes priority
[10:37] guido_g :)
[11:34] wayneeseguin Is there an example of using zeromq with a C program ?
[11:34] wayneeseguin I am reading the docs but
[11:34] wayneeseguin would like a full example to look at
[11:39] wayneeseguin Perhaps I can glean this from mongrel2...
[11:43] guido_g wayneeseguin: see the guide
[11:43] guido_g full of c it is
[11:44] wayneeseguin guido_g: I've ben looking at
[11:45] wayneeseguin guido_g: But I was looking for a simple example of usage, is there another page with that? or is that not the guidee
[11:47] headzone wayneeseguin:
[11:47] headzone every example is available in c
[11:52] wayneeseguin *awesome*
[11:52] wayneeseguin thank you both
[11:52] wayneeseguin I was simply looing at the wrong pages :)
[17:14] seangrove Hey all, what are unnamed sessions, and why would an assertion about them be failing?
[17:18] mikko seangrove: what is the exact assertion?
[17:19] seangrove Assertion failed: unnamed_sessions.empty () (socket_base.cpp:507)
[17:20] seangrove So, I'm probably mixing up a few pieces here
[17:20] seangrove But trying to get my head around some of the vocabulary
[17:24] seangrove hmm
[17:24] seangrove So this seems to happen right around forking
[17:25] seangrove If I call after forking, or don't call it at all, I get the assertion failure and a segfault
[17:25] seangrove If I call before forking, I only get the assertion failure
[17:28] seangrove mikko: Any suggestions on where to read up to understand this?
[17:31] mikko you should have one context per process
[17:32] mikko i don't think context survices fork
[17:32] mikko what language is this?
[17:32] seangrove Ruby
[17:33] seangrove I know the one-context-per-process
[17:33] seangrove Should I create a new context in the parent pre-fork, the child-post-fork, or the parent-post-fork?
[17:33] seangrove I believe the guide says in the parent pre-fork
[17:35] mikko i think in each child after fork
[17:35] seangrove Hmm, that gets me a segfault
[17:36] seangrove I wonder if it's a library version problem
[17:36] seangrove Certainly possible
[17:37] seangrove And is that regardless of whether the child process uses anythign zmq-related?
[17:37] seangrove None of my child processes do anything with zmq
[17:53] sustrik seangrove: if you create new context in the child if should work ok
[17:53] sustrik if it does not, it's a bug
[17:53] sustrik please, do report it
[17:56] seangrove sustrik: Ok, sounds good
[17:56] seangrove Thanks for the tip
[17:56] seangrove I need to refactor zmq out of the frontend of my app right now anyway
[17:57] seangrove Put it where it really belongs