0

I want to connect to Unix Domain Socket created by ZeroMQ (IPC model) via command nc. I can connect, but when I sending some messages then, my deamon, which is listening to this socket, is not getting any message...

I'm using nc like:

nc -U /path/to/socket
user3025978
  • 477
  • 2
  • 8
  • 27
  • What are you sending via nc? Does it match the zmq message protocol? – David Jan 05 '17 at 13:15
  • To add to the comment from @David, a program using ZeroMQ is expecting to talk to another program that talks the same protocol, ZMTP. The easiest way to do that is to have another program that also uses the ZeroMQ library. netcat is not that. ZeroMQ implements a message queue on top of stream connections like sockets, pipes, etc, so one would not expect to see your message data emerging from the socket. Whatever it is you are trying to do, there's almost certainly a suitable binding of ZMQ for the language of your choice, probably even bash. – bazza Jan 16 '17 at 20:46
  • @bazza please add this as answer, I will accept – user3025978 Jan 17 '17 at 08:25

1 Answers1

3

Very well, here's a longer version.

ZeroMQ implements a message queue transport system over the top of stream connections like sockets, named pipes, etc. To do this it runs a protocol called ZMTP over the top of the stream, which provides all the message demarcation, communication patterns, and so forth. It also has to deal with protocol errors in order to give itself some resiliency.

Comparison to a Web Browser

It's the same idea to a web browser and web server communicating using http over a socket. Http is used to transport html files. If you look at the data flowing over the socket you see the html mixed up with the messages involved in running the http protocol. And because http is a text based protocol, it looks kinda OK to the human eye.

Talking the Same Language

Thus when a program that uses the zmq libraries for communication connects a socket / named pipe / etc, it will be expecting to exchange data over that connection in the way defined by the ZMTP protocol (in the same way a web browser is expecting to talk to a server using http). If the program at the other end is also using zmq, then they're both talking the same protocol and everything is good.

Incompatible Protocols

However, if you connect a program that doesn't of itself use the ZMTP protocol such as a web browser, and that sends a http request, it's unlikely to mean anything. And the zmq library routines will no doubt receive the bytes that make up the http request, attempt to interpret it, fail to understand it, and ultimately reject it as garbage.

Similarly if the program that uses the zmq library wants to send messages, nothing will happen unless the underlying ZMTP protocol driver is content that it is communicating with something else that talks ZMTP. If anything at all emerges from netcap, it won't look anything like the message you were sending (it'll be jumbled up with the bytes that ZMTP uses).

Human Equivalent

The equivalent is an Englishman called Bob picking up the phone and dialling the number for his English friend called Alice living in Paris. However, if a Frenchman called Charlie answers the phone by mistake (wrong number), it'll be very difficult for them to exchange information. Meanwhile Eve, who's tapped the phone line, is laughing her head off at the ineptitude of these two people's failed attempt to communicate. (I make sweeping and partly justifiable generalisations about us Englishmen's poor ability to speak any other language).

Way Forward

There's a ZMQ binding available for almost everything, possibly even bash. Whatever it is you're trying to accomplish it's probably well worth while getting a decent binding of ZMQ for the programming or scripting language your using, and use that to provide a proper ZMQ endpoint.

bazza
  • 7,580
  • 15
  • 22
  • would you mind to kindly expand your "nightmare" part of your profile -- in what you permit to care to remember from the InMOS Transputer era? What is of a particular interest is what was the basis for the expressed preference of ( a "just" `SEQ` ) C-language to the **fully hardware supported `PAR` occam?** Thank you. – user3666197 Jan 18 '17 at 11:46
  • Debugging was a true nightmare. You couldn't even do printf debugging except on the one Transputer in the network that was connected to the host PC. Great hardware, great languages (I used their C, not Occam), very hard and slow to develop for, very satisfying once running well. As soon as Intel got to 66MHz, Inmos were doomed. You could get the same performance from a single thread on an Intel x86 that you could get from a large network of Transputers. Plus they were late with the T9000. – bazza Jan 18 '17 at 21:04
  • But yes, the parallelism in the language and hardware was very nice. If I implement my own CSP framework I still call the major routine procAlt(). That was Inmos C's equivalent of Occam's PAR, I think. Happy, but hard days. Oddly enough some of Inmos's silicon was accidentally quite rad hard, so it got used in some spacecraft like Giotto (if my memory is correct) – bazza Jan 18 '17 at 21:16
  • I vaguely recall that the tools for the Meiko Compute Surface were a bit kinder to work with, plus they made impressive looking, super-computer-esque cabinets that ran a pretty impressive ray tracing demo. – bazza Jan 18 '17 at 21:22
  • Meiko understood the value of a dynamic interconnect. With just Transputers you were wiring them together in a fixed topology, which meant that you either had to have a fixed topology application, or handle the message routing yourself. Meiko did an interconnect chip that went in between the Transputers that meant the connections were no longer hardwired, and some could be run time dynamic. The equivalent today is the Serial RapidIO switch chips that you find on the cards in the middle of an OpenVPX system, especially those from www.mrcy.com. – bazza Jan 18 '17 at 21:30
  • As for ZMQ, it implements Actor Model programming. It very nearly does CSP, though it's impossible to actually disable the message buffering between endpoints completely. A send/recv in ZMQ is not a rendevous like sending messages down a Transputer channel is. – bazza Jan 18 '17 at 21:34
  • Many thanks, Sir, for sharing your hands on experience & impressions collected during this unique and trully native `PAR` epoch. Once more, thank you. – user3666197 Jan 18 '17 at 21:39
  • Well, I would not guess to say that any distributed-system's debuggin is a true nightmare. As for ZeroMQ, I've spend good & bad times with distributed-systems integration based right on ZeroMQ signalling & messaging services. Nice and inspirative piece of thinking from Pieter Hintjens' & Martin Sustrik's team – user3666197 Jan 18 '17 at 21:41
  • No worries. Yes, ZMQ is excellent. It wasn't the distributed nature of Transputer systems as such that made them hard debug, more that there were no means other than comms via the inter-Transputer channels over which debugging or even I/O could be done. There was no JTAG or any equivalent on the chips themselves that would allow you to debug that chip and the code running on it. – bazza Jan 18 '17 at 22:37