It’s hard to say without seeing a sample for the client process as well. One thing is you want to use nn_connect for REQ and nn_bind for REP, but you may have already tried that You may also want to check return values on calls to nn_connect and nn_bind I would insert some debug printing into nn_device_mvmsg. You will have to recompile nanomsg for this. If that function is called, it means that the device is moving messages between its two sockets. If it isn’t then that could indicate a problem between the client and the device. I would also try a simple test case involving REQ—> REP_RAW where you call nn_recv(req_raw, …). The data that you get when you receive on a raw REP socket may not make a lot of sense, but you should at least get some message, and if you don’t there is probably something wrong on the client side. Finally note that when using IPC transport the semantics are OS-defined. On OSX for example a file is created in the current working directory. If you have two programs that are run in two different working directories then you will get 2 files, the programs won’t communicate and you’ll get behavior like what you describe. I don’t know what other OSes do. Look into how your platform handles IPC or switch to TCP which you can debug with wireshark. On Jun 17, 2014, at 3:29 AM, Ramakrishna Mallireddy <ramakrishna.malli@xxxxxxxxx> wrote: > Can anyone point me where I am going wrong, can I use Wireshark or any > similar process to view nanomsg network data. >