Re: [zeromq-dev] Titanic SP with encrypted data transfer
Thank you very much for the answer Pieter, On Fri, Dec 14, 2012 at 12:23 AM, Pieter Hintjens p...@imatix.com wrote: On Thu, Dec 13, 2012 at 11:42 PM, Jovan Kostovski chomb...@gmail.com wrote: I know that ZeroMQ supports TLS shared keys encryption... It doesn't, yet, unfortunately. Hm... I know that ZMQ does not support it by it self,but I saw some example[1] which use TLS shared key encryption, so I wanted now what are the options... If you need encryption, you will need to either do it at a lower layer (VPN) If I use VPN it won't affect the the ZMQ sockets and messages, It would just be a ZMQ communication through a secure channel, right. You can also encrypt per message, using pre-shared keys, which is the least nasty option IMO. I think I'll go for this solution because it does not affect the ZMQ messaging layer and it would be easy just to encrypt the message payload (the message bodies) I do hope we find a better general solution at some stage; you are not the only person who hits this. Are there any ideas how to support this except the once on http://www.zeromq.org/topics:encryption ? I'm willing to help in the development BR, Jovan References: [1] https://github.com/ianbarber/TLSZMQ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Titanic SP with encrypted data transfer
ugh, this has been on my list for some time, slowly moving up the priority chain... (current target is mid-spring) https://github.com/wesyoung/libzmq if you wanna port it up the 3x tree and fiddle with it a bit. haven't touched it in a few months, and even then, only got it to compile. could someone post this to the encryption doc as a reference? i can't due to low karma.. :) On Dec 14, 2012, at 4:52 AM, Jovan Kostovski wrote: Thank you very much for the answer Pieter, On Fri, Dec 14, 2012 at 12:23 AM, Pieter Hintjens p...@imatix.com wrote: On Thu, Dec 13, 2012 at 11:42 PM, Jovan Kostovski chomb...@gmail.com wrote: I know that ZeroMQ supports TLS shared keys encryption... It doesn't, yet, unfortunately. Hm... I know that ZMQ does not support it by it self,but I saw some example[1] which use TLS shared key encryption, so I wanted now what are the options... If you need encryption, you will need to either do it at a lower layer (VPN) If I use VPN it won't affect the the ZMQ sockets and messages, It would just be a ZMQ communication through a secure channel, right. You can also encrypt per message, using pre-shared keys, which is the least nasty option IMO. I think I'll go for this solution because it does not affect the ZMQ messaging layer and it would be easy just to encrypt the message payload (the message bodies) I do hope we find a better general solution at some stage; you are not the only person who hits this. Are there any ideas how to support this except the once on http://www.zeromq.org/topics:encryption ? I'm willing to help in the development BR, Jovan References: [1] https://github.com/ianbarber/TLSZMQ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev -- Wes wesyoung.me signature.asc Description: Message signed with OpenPGP using GPGMail ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Zyre info request
Some time ago there was a discussion about auto discovery where zyre was mentioned. Since then I downloaded, compiled and installed and tried running the -minimal- examples. No luck: the sender fails no matter what I use as second parameter. I searched here and there for documentation but it seems pretty scarce. Can anyone suggest any in depth doc alloy zyre? I especially need message passing, file passing is quite down in the priority list. Thanks Claudio -- Sent from my ParanoidAndroid Galaxy Nexus with K-9 Mail.___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Unable to use PGM (compiled yet protocol not supported)
Using stable 3.2.2, i compiled this way ./autogen.sh --with-pgm ./configure sudo make install I can see these files being compiled CXXlibzmq_la-pgm_receiver.lo CXXlibzmq_la-pgm_sender.lo CXXlibzmq_la-pgm_socket.lo among the others, yet any program attempting to use PGM reports the error Protocol not supported. What am I doing wrong? Claudio ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] C++ syntax for new ZMQ objects
Hello all.
I'm surely a noob in C++, so I am having difficulties managing ZMQ in
this language.
I'm creating a class that will include both a client and a server so I
have this structure
namespace Saetta
{
class Server
{
public:
Server(void);
virtual ~Server();
void worker();
private:
std::string _base_ip_address;
int _client_list[];
int _counter;
char _count[3];
zmq::context_t _zmq_context;
zmq::socket_t _zmq_socket;
};
class Client
{
public:
Client(void);
virtual ~Client();
void worker();
private:
zmq::context_t _zmq_context;
zmq::socket_t _zmq_socket;
};
}
I have to convert the basic
zmq::context_t context(1);
zmq::socket_t publisher(context, ZMQ_PUB);
publisher.bind(tcp://*:);
into something feasible for my class.
So I thought writing this into the constructor
this-_zmq_context = new zmq::context_t(1);
this-_zmq_socket = new zmq::socket_t(this-_zmq_context, ZMQ_PUB);
this-_zmq_socket.bind(tcp://*:);
None of this works.
Hope there is somebody kind enough to explain to me how should I phrase
the declarations to have them work with ZMQ.
Thank you
Claudio
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Zyre info request
Hi Claudio, Some time ago there was a discussion about auto discovery where zyre was mentioned. Since then I downloaded, compiled and installed and tried running the -minimal- examples. It is actually documented from the inside out, starting in Chapter 8 of the Guide. If you just want to use it, rather less easy right now. We'll start putting together some basic docs soon. Start by getting zre_ping to run and connect to other nodes. Your network interface must support UDP broadcasts, so no loopback. At the least, an Ethernet connection, or WiFi. -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Zyre info request
On 14/12/12 19:56, Pieter Hintjens wrote: It is actually documented from the inside out, starting in Chapter 8 of the Guide. Thanks, that's some nice reading. If you just want to use it, rather less easy right now. We'll start putting together some basic docs soon. Start by getting zre_ping to run and connect to other nodes. Your network interface must support UDP broadcasts, so no loopback. At the least, an Ethernet connection, or WiFi. I'll see what I can do. When I first tried I didn't get the requirement for 2 computers, but it's obvious when you think of it: no multicast on loopback. Thank you Claudio ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Zyre info request
You can run many nodes on one computer (e.g. zre_tester), but you need a network interface that supports broadcast; loopback doesn't do that. Here's what ifconfig shows on my laptop: eth0 Link encap:Ethernet HWaddr e8:11:32:c4:01:13 inet addr:192.168.0.136 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::ea11:32ff:fec4:113/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6360804 errors:0 dropped:0 overruns:0 frame:0 TX packets:3942846 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:8152408546 (8.1 GB) TX bytes:752858841 (752.8 MB) Interrupt:41 Base address:0xa000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:926866 errors:0 dropped:0 overruns:0 frame:0 TX packets:926866 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2015220456 (2.0 GB) TX bytes:2015220456 (2.0 GB) But if I unplug the Ethernet cable then eth0 stops working. So I need my eth0 up and connected in order to run multiple nodes on a single machine. We could eventually use another discovery mechanism for loopback. -Pieter On Fri, Dec 14, 2012 at 8:24 PM, Claudio Carbone erup...@libero.it wrote: On 14/12/12 19:56, Pieter Hintjens wrote: It is actually documented from the inside out, starting in Chapter 8 of the Guide. Thanks, that's some nice reading. If you just want to use it, rather less easy right now. We'll start putting together some basic docs soon. Start by getting zre_ping to run and connect to other nodes. Your network interface must support UDP broadcasts, so no loopback. At the least, an Ethernet connection, or WiFi. I'll see what I can do. When I first tried I didn't get the requirement for 2 computers, but it's obvious when you think of it: no multicast on loopback. Thank you Claudio ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] socket writability and events
Hi, Is it possible that a socket could be determined to be writable but then actually isn't writable at the time of write? For example, say a connection exists on a bind socket and ZMQ_POLLOUT is indicated. But then just before calling zmq_send(), the connection is destroyed. A socket that was using bind should have no queue anymore, and therefore I would expect the send to actually block (or report EAGAIN). I just want to confirm this is indeed possible. Secondly, assuming the above is true, if you're doing an event loop integration and checking ZMQ_EVENTS after every call to zmq_send, do you still need to check the events even if zmq_send fails? My guess is that if it fails with EAGAIN, that you probably should check the events (especially if the reason you attempted a write in the first place is because ZMQ_POLLOUT was indicated prior). What I'm doing in my code now is checking events after success or EAGAIN, but not checking in any other case. Looking for confirmation on this as well. Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] socket writability and events
Part 1. the behaviour isn't documented but what you suggest makes sense. You should be able to reproduce it. Part 2. not documented, again, would need to test to be sure. Once we have reproducible cases we can see whether these are bugs to fix, or expected effects to document. -Pieter On Fri, Dec 14, 2012 at 9:40 PM, Justin Karneges jus...@affinix.com wrote: Hi, Is it possible that a socket could be determined to be writable but then actually isn't writable at the time of write? For example, say a connection exists on a bind socket and ZMQ_POLLOUT is indicated. But then just before calling zmq_send(), the connection is destroyed. A socket that was using bind should have no queue anymore, and therefore I would expect the send to actually block (or report EAGAIN). I just want to confirm this is indeed possible. Secondly, assuming the above is true, if you're doing an event loop integration and checking ZMQ_EVENTS after every call to zmq_send, do you still need to check the events even if zmq_send fails? My guess is that if it fails with EAGAIN, that you probably should check the events (especially if the reason you attempted a write in the first place is because ZMQ_POLLOUT was indicated prior). What I'm doing in my code now is checking events after success or EAGAIN, but not checking in any other case. Looking for confirmation on this as well. Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] socket writability and events
Ok some quick testing within my app confirms that EAGAIN will be returned if a socket turns out to be unwritable, even after indicating writability. For example, if a tcp connection is established, POLLOUT is indicated, the tcp connection is broken, and then a write is attempted. Personally I think this is fine. I'd rather know that the socket is unwritable rather than the alternative which would be to eat the message. It is a bit of a gotcha though, for anyone used to internet sockets (or pipes in general), where if a socket is said to be writable then this condition cannot be revoked (well, I suppose that's not quite true, we have the lovely EPIPE there instead). Also, this I think this can only ever happen with bind sockets. So the behavior could go away someday if bind sockets ever get their own outbound queues that live independent of peer connections. As for part 2: it seems the unavailablity of writes is actually notified via ZMQ_FD through the lack of POLLOUT being set in the events. I'd never considered taking action by the absense of this flag until now. This means my app learns about unwritability immediately and the window of opportunity to write to a socket that is no longer unwritable becomes very very small. I also believe this means it is unnecessary to poll the events after a failed zmq_send. On Friday, December 14, 2012 11:46:09 PM Pieter Hintjens wrote: Part 1. the behaviour isn't documented but what you suggest makes sense. You should be able to reproduce it. Part 2. not documented, again, would need to test to be sure. Once we have reproducible cases we can see whether these are bugs to fix, or expected effects to document. -Pieter On Fri, Dec 14, 2012 at 9:40 PM, Justin Karneges jus...@affinix.com wrote: Hi, Is it possible that a socket could be determined to be writable but then actually isn't writable at the time of write? For example, say a connection exists on a bind socket and ZMQ_POLLOUT is indicated. But then just before calling zmq_send(), the connection is destroyed. A socket that was using bind should have no queue anymore, and therefore I would expect the send to actually block (or report EAGAIN). I just want to confirm this is indeed possible. Secondly, assuming the above is true, if you're doing an event loop integration and checking ZMQ_EVENTS after every call to zmq_send, do you still need to check the events even if zmq_send fails? My guess is that if it fails with EAGAIN, that you probably should check the events (especially if the reason you attempted a write in the first place is because ZMQ_POLLOUT was indicated prior). What I'm doing in my code now is checking events after success or EAGAIN, but not checking in any other case. Looking for confirmation on this as well. Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Unable to use PGM (compiled yet protocol not supported)
On Fri, Dec 14, 2012 at 5:15 PM, Claudio Carbone erup...@libero.it wrote: http://lists.zeromq.org/mailman/listinfo/zeromq-dev Pass the --with-pgm flag on the configure. Ian ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
