Lecture 9

Questions for the professor

First off, a couple lectures back you gave a shoutout to a professor named Richard Stevens, who you said had great material to learn more on networking. I took a look around, which let me to a bunch of textbooks that he wrote. I've read the first 7 chapters of volume 1 of "UNIX Network Programming", this Richard Stevens guy is a great writer. From what I can tell, he seems to have built quite a legacy for himself.

• Once you have a socket, and you've accepted a connection on the server-side, how exactly is data passed back and forth?

  Answer: Every socket has a file descriptor, whose number is returned by the call to socket(2). Reading and writing to this file descriptor is how we communicate.

• We use C system calls to read and write, and we write code that wraps around these system calls, but ultimately, those calls to read(2) and write(2) are what are sending data around. Can you use C++ streams to read and write? Is there a reason we chose not to?

  Answer: I'm not sure, give it a try.

  My answer: the Wikipedia Overview of File Descriptors cautions that network sockets is a rare instance in which a file descriptor refers to an object that does not normally exist in the file system, the other being anonymous pipes, so take caution.

• Is the socket call to accept(2) a blocking function?

  Answer: Yes, from the manual page:

  If pending connections are present on the queue, and the socket is not marked as nonblocking, accept() blocks the caller until a connection is present.

• At the end of the program, we tell the socket to close(), what happens if we don't do that? When it falls out of scope, it doesn't close itself?

  The file descriptor would continue pointing to the socket, but the socket would never be reused. Eventually we run the risk of running out of file descriptors

• So far, our networking labs & PAs are having us use TCP stream sockets. Will future labs / PAs have us build a server that uses UDP datagram sockets, or will we be sticking to TCP for assignment-related code.

  Answer: We will only use TCP sockets.

• What would have to change, if anything, to allow the remote host (say, from within the local network, to begin with), to connect to our server? I've heard the phrase bind to all interfaces thrown around before.

  Answer: I'm not sure.

• What part of the code instantiating a socket for a server prevents it from raising the exception address in use

  The call to setsockopt(2) in which we supply the option SO_REUSEADDR, whose purpose is defined in socket(7):

  Indicates that the rules used in validating addresses supplied in a bind(2) call should us to reuse local addresses. For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address. When the listening socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address. Argument is an integer boolean flag.

On Linux, the set of file descriptors open in a process can be accessed under the path /proc/PID/fd/ replacing PID with the identifier of the current process.

I went to discussion this week, and asked Shuhan the following questions about the code written by our professor, included in snippets below:

An interrupt can be ignored by a call to signal(2), but this is risky, the modern way is to call sigaction(2), and use the macro SIG_IGN to tell the program to respond to SIG_INT by ignoring it.

• Makefiles, where am I going wrong?

Docs just now