Lab 5 - Daemon code continued

Due: Thursday by 5pm

The purpose of this lab is to take the concept of using select() from Lab 3 to create an improved version of vcrec and vcsend from Lab 2. This lab is worth 10 points.

In Lab 2, you created a half-duplex form of both vcrec and vcsend by alternating the code to send data and the code to receive data. So the flow of information was:

vcsend          vcrec
send()  ----->  recv()
recv()  <-----  send()
send()  ----->  recv()
recv()  <-----  send()
For this lab, you are going to alter those send/receive loops in both vcsend and vcrec to instead use select() to determine whether to call send() or recv().

You will call send() when there is data on standard in, which indicates the user has typed something to send, unless the user has typed just a period (.) on a line by itself, which indicates that the user wishes to close the connection. Use code similar to vcsend.c to read the data in from stdin (or your own code with similar functionality). Also be sure to check the return value of send() as vcsend.c did.

You will call recv() when there is data waiting to be read on the socket. If recv() is successful (returns greater than 0), print the data to the screen. Otherwise (returns 0 or negative number), handle as the original vcrec.c handled those return values of recv().

Be sure to prompt the user for input before entering the select() loop and at the end of a normal select() loop iteration (one that did not error or exit). The prompt can be any text you choose, but be sure to indicate that the user types '.' on a line by itself to close the connection.

Test your code by running vcrec and then having vcsend connect to vcrec's port. You should be able to type in either program whenever you want and have the data display via stdout on the other program. Both programs should terminate when you type '.' on a single line in either program.

Email me your new and improved versions of vcsend and vcrec.

Also, answer the following questions. In Lab 4, daemon allowed more than one client to connect at once and would fork off a child process for each client. One main difference between daemon and this improved vcrec is that daemon only called recv(), so each child process only had to receive data from the client and print it to standard out.

  1. What would be one major obstacle to supporting multiple clients with vcrec (hint: think about what happens to standard in when children processes are forked)?
  2. Obviously there is a way around this obstacle otherwise interactive sessions wouldn't work. List one way you'd try to get around this obstacle.