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
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:
- 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.
- 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.
- 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 . |
|