Friday June 18, 2010
| [Time] Name | Message |
|---|---|
| [00:54] achew22 | can anyone point me to a good introduction to zeromq that focuses on python? |
| [06:55] umesh | I read some code in zeromq ... |
| [06:55] umesh | i have some queries related to it |
| [06:56] umesh | I have observed that in zmq for req/rep ... it uses normal tcp/ip apis internally ... |
| [06:56] umesh | like listen, bind, connect, accecp, recv and send etc ... |
| [06:57] umesh | but when we close the server generall read or recv returns 0 when server is shutdown using cntrl-c or exit or abort ... |
| [06:58] umesh | but in case of zmq recv does not return 0 when server is closed using exit or abort |
| [06:58] umesh | why ? |
| [07:55] sustrik | becore there are N connections |
| [07:55] sustrik | because* |
| [07:56] sustrik | one failing doesn't make other unusable |
| [08:17] umesh | sustrik: I did not understood your answer very clearly |
| [08:18] sustrik | 0mq sockets can have arbitrary number of BSD sockets under the hood |
| [08:18] sustrik | if one of the BSD sockets fail |
| [08:18] sustrik | the others are still up and kicking |
| [08:20] mikko | is there any way to know that send to one endpoint failed? |
| [08:20] mikko | is there a need to know ever? |
| [08:20] sustrik | there's no such thing as "send to one endpoint" |
| [08:20] sustrik | if you want that kind of stuff, use BSD sockets directly |
| [08:21] mikko | maybe i misphrased |
| [08:21] mikko | i mean if i connect 0mq socket to three endpoints and one of them is unreachable. as a developer do i need/want to know about that? |
| [08:22] sustrik | the design of 0mq is such that you don't know |
| [08:22] sustrik | it's like speaking to a cloud |
| [08:22] sustrik | if you want to manage connections on one-by-one basis, that's what BSD sockets are for |
| [08:23] mikko | fire and forget |
| [08:24] sustrik | yes |
| [08:25] mikko | i started working on http device but got stuck on figuring out SLAs for different things at work |
| [08:26] sustrik | no haste :) |
| [08:29] mikko | the thing i like about imatix page is that it lists prices for professional services |
| [08:29] mikko | that is nice and transparent |
| [08:30] mikko | most of the companies have phone number and you need to go through hoops to get prices |
| [08:30] sustrik | yes, experienced that myself |
| [08:32] sustrik | presumably, the price is not the same for everyone |
| [08:32] mikko | yeah, that's what i assume |
| [08:32] mikko | the bigger company calling the bigger the price is |
| [08:33] mikko | makes it very hard to calculate costs for a project especially under very strict NDA |
| [08:39] sustrik | true |
| [10:44] umesh | sustrik: you remember on that day we discussed about the writing a sync 0mq client |
| [10:44] umesh | and you told discussion happended couple of times but no one really did it ... |
| [10:44] umesh | I can do it ... |
| [10:44] umesh | can you give me some pointers ... |
| [10:45] umesh | on this ... |
| [10:45] umesh | how can we do it etc ... |
| [10:45] sustrik | umesh: it's easy |
| [10:45] sustrik | have a look at zmq_tcp(7) |
| [10:45] sustrik | the wire format section |
| [10:46] sustrik | that's how 0mq messages look like on the wire |
| [10:46] sustrik | so the only thing you have to do is to open a TCP socket |
| [10:46] sustrik | and read/write such messages |
| [10:46] sustrik | and report errors :) |
| [10:49] umesh | ok |
| [15:13] cremes | going async to sync... i just don't see the point to doing that; async is perfect already |
| [15:19] sustrik | error handling i suppose |
| [15:32] cremes | pffftt; that's what error callbacks are for. |