Socketpair() in C/Unix

You can use socketpair only where you create both processes, like so:

1. call socketpair - now you have two socket file descriptors (two ends of a single pipe)
   • nominate one end to be the parent and one to be the child end. It doesn't matter which, just make a choice and stick to it later
2. call fork - now you have two processes
   1. if fork returned zero, you are the child. Close the parent file descriptor, keep the child descriptor, and use it as this process's end of the pipe
   2. if fork returned non-zero, you are the parent. Close the child file descriptor, keep the parent one and use it as your end of the pipe
3. you now have two processes, each has one file descriptor representing different ends of the same pipe. Note that both processes are running the same program, but they followed a different branch after calling fork. If parent calls write on its socket, child will be able to read that data from its socket, and vice-versa

Here is a straight translation into code:

void child(int socket) {    const char hello[] = "hello parent, I am child";    write(socket, hello, sizeof(hello)); /* NB. this includes nul */    /* go forth and do childish things with this end of the pipe */}void parent(int socket) {    /* do parental things with this end, like reading the child's message */    char buf[1024];    int n = read(socket, buf, sizeof(buf));    printf("parent received '%.*s'\n", n, buf);}void socketfork() {    int fd[2];    static const int parentsocket = 0;    static const int childsocket = 1;    pid_t pid;    /* 1. call socketpair ... */    socketpair(PF_LOCAL, SOCK_STREAM, 0, fd);    /* 2. call fork ... */    pid = fork();    if (pid == 0) { /* 2.1 if fork returned zero, you are the child */        close(fd[parentsocket]); /* Close the parent file descriptor */        child(fd[childsocket]);    } else { /* 2.2 ... you are the parent */        close(fd[childsocket]); /* Close the child file descriptor */        parent(fd[parentsocket]);    }    exit(0); /* do everything in the parent and child functions */}

Please note that this is just sample code: I've left out all error-checking and a sensible stream protocol.

If you want two separate programs to communicate (eg. you have an executable called client, and one called server), you can't use this mechanism. Instead, you might:

• use UNIX sockets (where an IPC pipe on one host is identified by a filename - this only works if client and server run on the same machine)
• or use TCP/IP sockets (where an IP address and port identify the pipe, and the client and server can be on different machines)

If you don't specifically need sockets, and you're happy to require that client and server run on the same machine, you can also use shared memory, or message queues.

socketpair creates an anonymous pair of sockets, usually unix/local sockets, which are only useful for communication between a parent and child process or in other cases where the processes that need to use them can inherit the file descriptors from a common ancestor.

If you're going to do communication between unrelated (in the sense of parentage) processes, you need to use socket, bind, and connect to create a listening socket in one process and create a client socket to connect to it in the other process.

For communicating between two processes, yes, Inter Process Communication or IPC is what you should look for.Sockets are just one of the methods for communicating and is useful if you have to implement one-to-many connection. Means, one server process which communicates with many client processes in a request-response fashion. As you are a newbie to IPC, it is understandable that socket addresses and the details involved might look difficult to grasp. (Though you will find them easy in due time :-))

For your problem, I suggest you use simpler IPC mechanisms like Pipe, FIFO, Message Queue.I am not sure how you came to the conclusion to use socketpair. Since you have not mentioned anything around the design or kind of IPC you need AND bassed on usage level I strongly recommend to look into Pipe or FIFO sample codes in some book or internet. They should look way easier to implement and work faster than sockets.