Comments on the Use of Hands-On Networking

September 7, 2002. In about 45 and a half hours College's Fall 2002 semester will begin. CPSC370, Computer Networks, will be using Hands-On Networking for the first time. I would certainly not presume to say that I know how this remarkable text should be used in such a course, and I am sure that my views on this question will change through the semester, but my current plan is assign experiments in four basic blocks.
1. Client/server programming - chapters 5, 6, and 7.
2. Packet capture analysis - chapters 12 and 13.
3. A few miscellaneous experiments yet to be chosen.
4. Dedicated Intranet Lab experiments - chapters 15, 17, and perhaps 18.
In addition to these "regular" projects chapter 8 will be used as a course project. I do not expect that every student will be able to complete that chapter, and I will tell them so. Chapter 20 will be used for those taking the course for honors. This is probably ambitious, but at least they won't run out of things to do. Feel free to consult the course schedule. This plan seems to require some creative use of the main text, Computer Networks and Internets. It seems desirable to get an early start on client/server programming, hence the out of order treatement given to chapters 26 and 27.

September 28, 2002. So far we have had three lab and six classroom sessions. We have gone over chapters 3 through 6, and 26 and 27 (with a peak at 28) of Computer Networks and Internets. The lab sessions have been particularly interesting. Our first meeting of the year was in the lab, and we faced a shortened schedule. I tried to introduce client/server programming and

gdb

by stepping through some programs. The second lab involved modifying some previously written chat software. Following the second Optional Extension of Experiment 5.2 (page 24 of Hands-On Networking I had it sending one character at a time. However, data was sent in turn until the current sender hit the return key. I showed them how to use the select function to display characters as they were typed or received from the other participant. This took just a bit longer than I had expected so we had to finish it in the first 10 minutes of the third lab. I then showed them how to convert a TCP client/server into a UDP version. This is something I seem to have had to do frequently, and whenever there has been a time gap between such events, it always takes me a while to figure out how to do it again. When we went over Chapter 27 in Computer Networks, we spent some time trying to work out a procedure for such conversion in the hope of clarifying the differences between the two protocols. That procedure turned out to be very helpful in the lab. In fact, following it let me make the conversion without having worked through it ahead of time and without notes.

change the string "tcp" to "udp".
change SOCK_STREAM to SOCK_DGRAM.
eliminate receive loops in favor of a simple recv call.

Server:
1. Take out the calls to listen and accept.
2. Change send to sendto and recv to recvfrom.
Client:
You do not have to make any additional changes to the client, but you may remove the connect call if you change send to sendto and recv to recvfrom.

In the lab I did not get to the last step (changing send and recv in the server) since we were running out of time. When we tested our changes, the client was able to contact the server, but the server's response did not get to the client. I asked them to think about that. I raised the issue in the classroom five days later. No one had figured it out, so we worked through it eventually getting to the point where they saw that without a connection and with the server not saving the client's ip address and port number, the behavior we had seen in the lab was exactly what we should have expected. I plan to make the last changes in the fourth lab and then move on to something very ambitious.

On Monday we will take the server described in Chapter 28 of the text and modify it to be concurrent using threads. I have worked through this, and I do have notes for this one. What I am hoping will happen is that with each thread incrementing the global variable visits, we will get some incorrect results. This will lead naturally into a discussion of mutex locks. The reason I plan to spend the time working through threads is that my students tell me that in the operating systems course they spent a lot of time on forking processes but not so much on threads. They will need to use them in Experiment 7.1 and in their semester project.

In two weeks the labs will shift to the dedicated intranet lab where we will "play with" our Cisco routers.