This page contains late breaking announcements from Dr. Hollingsworth and Joseph Dunnick (the TA).
Please check this page a couple of times a week.
Midterm #2 will be Thursday Nov. 13 in class
The final project proposals are due Monday Nov. 10 at 6:00 PM
You do not need to link -lnsl on Alpha
The C library (/usr/lib/libc.a) that is automatically included in a
link request contains the network related libraries.
How to submit projects
Tar all source code files, Makefile and typescript file.
submit it using submit program residing in ~jh01/BIN/submit.
>~jh01/BIN/submit 1 prog1.tar
Use lowercase letters for the command line request type
Please write your programs to use lowercase letters for the command line
request type argument as lowercase letters is what I will be using to test your program.
Example: client host addr somewhere.cs.umd.edu
(NOT client host ADDR somewhere.cs.umd.edu)
A small correction to Socket Handout
near line 48: memset((void *) &server, sizeof server)
should have a second argument of zero.
The TA will be out of town from Oct. 9th to
Oct 13th. The Oct 13th office hours will be moved to Oct. 6, due to the
final and project deadlines. Oct 6's office hours will be 10 - 12, 1 - 3.
You should use g++ to compile
Even if you programmed in C, you should use g++ to compile your project 2 or
you will likely get an error in /usr/include/c_asm.h.
READ THIS: Format for submission of project 2
Following is required format for submission of project 2.
Points will be deducted if you do not follow these guidelines.
- The Tar file you submit should only have the following files (with exactly
README (optional--if you want to mention anything in particular about your project)
- The Tar file should not be a tarred directory with the files inside it.
- Nothing (error messages,extraneous info) should be printed out in queue.c
- Make sure to use the -Wall option (the comment in the header file will not
be counted against you).
- Your makefile should compile everything by just typing "make". This will be
true in future projects as well.
Project 2 information
Following is some useful information for project 2.
- You will need to link in the pthreads libarary. To do this, and "-lpthread" to the end of your (g++) compile line.
- The manual page on the pthread_cond_timedwait() function is particularly helpful--read it.
- You should use the function pthread_get_expiration_np() to convert the time passed as a parameter in your dequeue function into a time understandable by the pthread_cond_timedwait() function. There is a manual page for it. However, there is a typo in the manual page when the define the timespec structure--tv.sec and tv.nsec should be tv_sec and tv_nsec.
- Although the pthreads book passes void functions to the pthread_create() functions, it appears that the alphas require functions which return a void*.
- When project 2 is tested, you should expect that I will create multiple queues, so program accordingly.
Acceptable warnings for Project 2
- "/usr/include/pdsc.h:506: warning: `/*' within comment" will not
have points taken off for it.
- "/usr/bin/ld: Warning: clog defined as GLOBAL DATA but is defined in a shared lib as a GLOBAL FUNC" will not have points taken off for it. This warning can be avoided by not including iostream.h in your queue.c file (and there should
be no reason to include it in any case).
- There should be no other warnings.
Project Proposal Deadline Extended
The Project proposal first draft is now due on Friday 10/24/97 at 6:00 PM in
Dr. Hollingsworth's office. We extended the project proposal to allow more
time to finish the class discussion of the Network layer.
Project 2 Test Cases
Project 2 Test Cases
How do I get a 53 byte packet?
Bit pack the VPI, CVI, PT, and CLP fields into 4 bytes. Create a char
array of 49 bytes. One byte can hold the checksum field. Even though the
sizeof function will specify 56 bytes, pass a size of 53 to the garbler,
and everything should work.
Node sequence number constraints
You may assume there will be no more than 48 nodes running at once.
You may assume the maximum node number is 256. (one byte's worth)
You may NOT assume sequential numbering of the nodes.
You may NOT assume the ID number of the ndoes will be between 0 and 48.
This means that some groups will have to consider the possibility of multi-cell
Some project advice
Here is some advice on the project. These are not requirements.
- It is a very good idea to have send and recv block dequeueing from an AppQ.
- A good use for the credits field is to flow control if your recv window
is full (and of course to start the sender back up once your window opens
- The sooner you start your connection threads, the simpler your system
Unaligned access error
Integers (and probably other primative data types longer than 1 byte) have to
be used on integer boundaries, aka only on every xth address where x is the
size of your data type.
If you see an unaligned access error, it probably means you have a char array
and you are trying to cast it to an int (or other data type) inbetween an
int boundary. For example:
*(int *)(char + 2) = 3;
would be the sort of thing that would cause an alignment problem.
The way to fix this is to use bcopy to extract your data or (probably easier)
pad your data structures to make them byte-aligned.
Note: Your packet struct is probably not causing the alignment if you followed
the bit packing information.
Note 2: Different architectures have different alignment requirements.
Sending Signal Cells over atm_garb_routing
The final verdict:
You may use garb_sendto_routing() to send your signal cells, with a zero
probablity of garbling or dropping. HOWEVER, if you can support signal cells
using plain old garb_sendto_normal(), this will be worth more points.