CMSC 417 - Hot News

for CMSC417

This page contains late breaking announcements from Dr. Hollingsworth and Joseph Dunnick (the TA). Please check this page a couple of times a week.

MT#2 and Final Project Proposal Dates Changed

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.

>tar cvf prog1.tar *

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 these names):
[m|M]akefile
queue.h
queue.[c|C]
driver.[c|C]
typescript
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

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 routing signals.

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 back up).
The sooner you start your connection threads, the simpler your system will be

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: char data[48]; *(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.