Unix Socket Programming Interview Preparation Guide
Download PDF
Add New Question

Unix Socket Programming Interview Questions and Answers will guide us now that Unix domain socket or IPC socket is a data communications endpoint that is similar to an Internet socket, but does not use a network protocol for communication. It is used in POSIX operating systems for inter-process communication. The correct standard POSIX term is POSIX Local IPC Sockets. So learn Unix Socket Programming with the help of this Unix Socket Programming Interview Questions with Answers guide

62 Unix Socket Programming Questions and Answers:

1 :: How do Sockets Work?

The implementation is left up to the vendor of your particular unix, but from the point of view of the programmer, connection-oriented sockets work a lot like files, or pipes. The most noticeable difference, once you have your file descriptor is that read() or write() calls may actually read or write fewer bytes than requested. If this happens, then you will have to make a second call for the rest of the data. There are examples of this in the source code that accompanies the faq.
Post Your Answer

2 :: What is with the second parameter in bind()?

The man page shows it as "struct sockaddr *my_addr". The sockaddr struct though is just a place holder for the structure it really wants. You have to pass different structures depending on what kind of socket you have. For an AF_INET socket, you need the sockaddr_in structure. It has three fields of interest:

sin_family
Set this to AF_INET.

sin_port
The network byte-ordered 16 bit port number

sin_addr
The host's ip number.
This is a struct in_addr,
which contains only one field,
s_addr which is a u_long.
Post Your Answer

3 :: If bind() fails, what should I do with the socket descriptor?

If you are exiting, I have been assured by Andrew that all unixes will close open file descriptors on exit. If you are not exiting though, you can just close it with a regular close() call.
Post Your Answer

4 :: When should I use shutdown()?

shutdown() is useful for deliniating when you are done providing a request to a server using TCP. A typical use is to send a request to a server followed by a shutdown(). The server will read your request followed by an EOF (read of 0 on most unix implementations). This tells the server that it has your full request. You then go read blocked on the socket. The server will process your request and send the necessary data back to you followed by a close. When you have finished reading all of the response to your request you will read an EOF thus signifying that you have the whole response. It should be noted the TTCP (TCP for Transactions -- see R. Steven's home page) provides for a better method of tcp transaction management.
Post Your Answer

5 :: Code Sample: a very simple client process.

/*
*The quick example below is a fragment of
* a very simple client process.
* After establishing the connection with
* the server it forks. Then
* child sends the keyboard input to the
* server until EOF is received and
* the parent receives answers from the server.
*
* variables declarations and error handling are omitted
*/
s=connect(...);

if( fork() ){
/*The child, it copies its stdin to the socket*/
while( gets(buffer) >0)
write(s,buf,strlen(buffer));

close(s);
exit(0);
}

else {
/* The parent, it receives answers */
while( (l=read(s,buffer,sizeof(buffer)){
do_something(l,buffer);

/* Connection break from the server is assumed */
/* ATTENTION: deadlock here */
wait(0); /* Wait for the child to exit */
exit(0);
}


What do we expect? The child detects an EOF from its stdin, it closes the socket (assuming connection break) and exits. The server in its turn detects EOF, closes connection and exits. The parent detects EOF, makes the wait() system call and exits. What do we see instead? The socket instance in the parent process is still opened for writing and reading, though the parent never writes. The server never detects EOF and waits for more data from the client forever. The parent never sees the connection is closed and hangs forever and the server hangs too. Unexpected deadlock!

You should change the client fragment
as follows:

if( fork() ) {
/* The child */
while( gets(buffer) }
write(s,buffer,strlen(buffer));

shutdown(s,1);
/* Break the connection
for writing, The server will detect EOF now.
Note: reading from the socket is still allowed.
The server may send some more data
after receiving EOF, why not? */
exit(0);
}
Post Your Answer
Add New Question