Douglas E. Comer


Computer Science Department
Purdue University
West Lafayette, IN 47907

webmaster: W. David Laverell


Companion Topics

Home

Book Information

Purpose of Site

Getting Started

Students

Faculty

"What's New"

"Coming Attractions"

"C Pointers"

Acknowledgements

 

 
Hands-On Networking: Experiment 8.1 Home > Student > Experiments > 8.1

Experiment 8.1

Chapter 8
8.1 8.2 8.3 8.4 8.5
I actually found it easier to combine several of Professor Comer's steps in this experiment. Then too I was thinking data transfer all the way (Experiment 8.3). Here's the order in which I did this experiment:

  1. Write the gateway program. Notice that you are to use UDP so if you modify an earlier TCP program you have several things to change. Start with a loop to get two requests, one to be a client, and one to be a server. Use a simple for loop for now assuming that your first contact will be the server and the second the client. Save the information as specified in line 4 of the experiment. Now enter an infinite loop (while(1) please) in which you receive datagrams, check the source, and send it on the the other host. This is a good application of the recvfrom and the sendto functions. This is a good place to use a select function so your gateway can time out and shut down.

  2. Write a server program that contacts the gateway with a request to be the server, gets an enrollment message, waits for some kind of GET request with the name of a file, opens the file, repeatedly reads 10 bytes or so, sends them, at end of file sends an end of file mark, closes the file and the socket, and terminates. The reason for sending such small chunks is simply that you will want to test your system with a relatively small text file, and you do not want to send it all at once.

  3. Write a client program that contacts the gateway with a request to be the client, gets the enrollment message, sends some kind of GET request with the name of a file, receives and prints datagrams until the end of file mark arrives, closes its socket and terminates.

Now modify your programs so that the server and client send strings as described under Gateway Registration Messages. The gateway will have to parse those strings. Write a function to do this. The parameters will be the address of the string and the addresses of the 11 variables, endpoint, unique_name, throughput, etc. The function must use strtok, not sscanf since not all the variables will appear in the string. Challenge: use only one loop in your function!

For testing purposes you will find suggested test values for delay in Number 3 of Experiment 8.2.

Now do Procedure and Details 7. Random numbers are easy to do in C so this will not be too hard.

Procedure and Details 8 presents extremely interesting challenges. The first thing you have to do is modify your gateway so that it uses threads. You need to think about the implications of the fact that all threads have access to the memory in the main program. It is interesting to ignore, for scientific purposes, this fact and to proceed on the (false) assumption that each thread can use the same buffer. The results are fascinating, but, of course, not correct. Define a struct to define the data concerning each incoming datagram, that must be passed to the thread, and use malloc to get the memory needed. Pass your parameters in a pointer to a struct, and let the thread deal with sending the datagram along. Try this first without worrying about having the thread sleep.

The second thing is to figure out is how to get the thread to sleep for a variable number of milliseconds. The UNIX sleep function takes a single argument in seconds, so that will not do. Let me save you some time by pointing out that usleep is not the answer either. See the reference at Stunnel.org (search for usleep). This page will explain why usleep will not work and point you in the direction of nanosleep.

Optional Extension Number 3 illustrates an important point. You should have message types because you will eventually include acknowledgements. Optional Extension Number 4 is good because it will aid in debugging later.



This site is maintained by W. David Laverell of the Computer Science Department at Calvin College. For assistance or corrections, please contact him at lave@calvin.edu.