Remember FIFOs? Remember how they can only send data in one direction, just like a Pipes? Wouldn't it be grand if you could send data in both directions like you can with a socket? Well, hope no longer, because the answer is here: Unix Domain Sockets! In case you're still wondering what a socket is, well, it's a two-way communications pipe, which can be used to communicate in a wide variety of domains. One of the most common domains sockets communicate over is the Internet, but we won't discuss that here.
|Published (Last):||27 October 2017|
|PDF File Size:||11.52 Mb|
|ePub File Size:||15.69 Mb|
|Price:||Free* [*Free Regsitration Required]|
Remember FIFOs? Remember how they can only send data in one direction, just like a Pipes? Wouldn't it be grand if you could send data in both directions like you can with a socket? Well, hope no longer, because the answer is here: Unix Domain Sockets!
In case you're still wondering what a socket is, well, it's a two-way communications pipe, which can be used to communicate in a wide variety of domains. One of the most common domains sockets communicate over is the Internet, but we won't discuss that here.
We will, however, be talking about sockets in the Unix domain; that is, sockets that can be used between processes on the same Unix system. Unix sockets use many of the same function calls that Internet sockets do, and I won't be describing all of the calls I use in detail within this document.
If the description of a certain call is too vague or if you just want to learn more about Internet sockets anyway , I arbitrarily suggest Beej's Guide to Network Programming using Internet Sockets.
I know the author personally. However, all data communication will be taking place through the sockets interface, instead of through the file interface. Although Unix sockets are a special file in the file system just like FIFOs , you won't be using open and read —you'll be using socket , bind , recv , etc. When programming with sockets, you'll usually create server and client programs.
The server will sit listening for incoming connections from clients and handle them. This is very similar to the situation that exists with Internet sockets, but with some fine differences. Without going into too much detail, I'll outline the steps a server program usually has to go through to do it's thing. While I'm at it, I'll be trying to implement an "echo server" which just echos back everything it gets on the socket.
Call socket : A call to socket with the proper arguments creates the Unix socket:. For the curious, see Beej's Guide to Network Programming for a good description of unconnected datagram sockets that applies perfectly well to Unix sockets. One more note: all these calls return -1 on error and set the global variable errno to reflect whatever went wrong. Be sure to do your error checking. Call bind : You got a socket descriptor from the call to socket , now you want to bind that to an address in the Unix domain.
That address, as I said before, is a special file on disk. Notice that we called unlink before bind to remove the socket if it already exists. Call listen : This instructs the socket to listen for incoming connections from client programs:. The second argument, 5 , is the number of incoming connections that can be queued before you call accept , below. Call accept : This will accept a connection from a client. This function returns another socket descriptor!
The old descriptor is still listening for new connections, but this new one is connected to the client:. The descriptor s2 is connected to the client, and is ready for send and recv , as described in the Network Programming Guide. Handle the connection and loop back to accept : Usually you'll want to communicate to the client here we'll just echo back everything it sends us , close the connection, then accept a new one.
Close the connection: You can close the connection either by calling close , or by calling shutdown. With all that said, here is some source for an echoing server, echos. As you can see, all the aforementioned steps are included in this program: call socket , call bind , call listen , call accept , and do some network send s and recv s.
There needs to be a program to talk to the above server, right? Except with the client, it's a lot easier because you don't have to do any pesky listen ing or accept ing.
Here are the steps:. How about code to talk to the echo server, above? No sweat, friends, here is echoc. In the client code, of course you'll notice that there are only a few system calls used to set things up: socket and connect. Since the client isn't going to be accept ing any incoming connections, there's no need for it to listen.
Of course, the client still uses send and recv for transferring data. That about sums it up. What if you wanted a pipe , but you wanted to use a single pipe to send and recieve data from both sides? Since pipes are unidirectional with exceptions in SYSV , you can't do it! There is a solution, though: use a Unix domain socket, since they can handle bi-directional data. What a pain, though! Setting up all that code with listen and connect and all that just to pass data both ways!
But guess what! You don't have to! That's right, there's a beauty of a system call known as socketpair this is nice enough to return to you a pair of already connected sockets! No extra work is needed on your part; you can immediately use these socket descriptors for interprocess communication. For instance, lets set up two processes. The first sends a char to the second, and the second changes the character to uppercase and returns it.
Here is some simple code to do just that, called spair. Sure, it's an expensive way to change a character to uppercase, but it's the fact that you have simple communication going on here that really matters. These can be any legal values at all, depending on which routines in the kernel you want to handle your code, and whether you want stream or datagram sockets. Finally, you might be curious as to why I'm using write and read instead of send and recv.
Well, in short, I was being lazy. See, by using these system calls, I don't have to enter the flags argument that send and recv use, and I always set it to zero anyway. Of course, socket descriptors are just file descriptors like any other, so they respond just fine to many file manipulation system calls.
Beej's Guide to Network Programming
Intro Hey! Socket programming got you down? Is this stuff just a little too difficult to figure out from the man pages? You want to do cool Internet programming, but you don't have time to wade through a gob of struct s trying to figure out if you have to call bind before you connect , etc.
Beej's Guide to Network Programming Using Internet Sockets