open unix domain socket (Linux)

[Dennisvr]

How do I open a unix domain socket under linux using Labview (7.1).

I would like to write messages to /dev/log.

thanx

Message Edited by Dennisvr on 01-27-2006 04:20 AM

[KvZ]

Hi,

I'm not sure what a unix domain socket is, but if it is a regular TCP/IP Socket you can use the TCP VI's to open TCP Sockets. If this is not the case please give more detail on what a unix domain socket is and how to interface with it?

Hope this helps

Karsten

[Dennisvr]

It's used for local communication between applications. Instead of using ip address and port numbers, it uses a file to open the socket connection. The System logging daemon (syslogd) creates the /dev/log socket, and every program/daemon/service can open it to send messages to syslogd.

I solved the problem some time ago by writing a library in C (libsyslog.so) that interfaces to the socket. I'm still interested if there are other methods to open unix domain sockets.

I can give you a source example of the C code if you're interested.

[rolfk]

---

@Dennisvr wrote:

It's used for local communication between applications. Instead of using ip address and port numbers, it uses a file to open the socket connection. The System logging daemon (syslogd) creates the /dev/log socket, and every program/daemon/service can open it to send messages to syslogd.

I solved the problem some time ago by writing a library in C (libsyslog.so) that interfaces to the socket. I'm still interested if there are other methods to open unix domain sockets.

I can give you a source example of the C code if you're interested.

---

I haven't heard the term you are using but the functionality sounds suspiciously like what I would call pipes. If that is so look at the pipe VIs that come with LabVIEW.

Rolf Kalbermatter

[Dennisvr]

Pipes and sockets are different things. At first I thougt they could be the same too, and I even tried opening it using the LabVIEW pipe functions, but that didn't work.

Look at this link, it explains how it works, even with some examples: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html

[rolfk]

---

@Dennisvr wrote:

Pipes and sockets are different things. At first I thougt they could be the same too, and I even tried opening it using the LabVIEW pipe functions, but that didn't work.

Look at this link, it explains how it works, even with some examples: http://www.ecst.csuchico.edu/~beej/guide/ipc/usock.html

---

I see. Well LabVIEW does not support this type of socket. The only socket interface it has already is the one used for its TCP/UDP implementation and that is using sockaddr_in internally to bind. As such you have two options:

1) Write your own domain socket interface writing a shared library and the according interface VIs.

2) Or use TCP/IP interprocess communication instead.

In terms of functionality TCP/IP will be the same as what you could possibly get from domain sockets. The only reason to use domain sockets instead of TCP/IP sockets might be that domain sockets have a more  optimized data transfer since they do not take precautions for remote data transfer. If you really need this (possible?) increased performance you will have to do some work.

However domain sockets seem little known and might be a new technology. So I would make sure it is properly supported on all the potential system you try to use this before taking the plunge to write your own shared library interface to call through the Call Library Node.

Rolf Kalbermatter

[Dennisvr]

I already implemented your suggestion 1, making my own interface library, and then accessing it with a call library node. It's not that hard, but I prefer to keep things inside LabVIEW for portability, just like you said. On the other hand, the service we're using isn't provided on a Windows system anyway, so that might not be a con.

The second option you mention isn't any good for me, because I can't really choose another way to communicate.

I don't believe these sockets are that new though, because as far as I know X-windows communicates to it's clients the same way.

PS. It's working quite good now. It's really nice to see these logging messages come in from different pc's, giving loads of information about the system.