• C

question on stop and wait arq protocol

I"m a novice, and working on a stop and wait protocol simulation. I'm wondering how can approach to show Error checking to be demonstrated by use of signals ie ^C – Damaged Frame ^Z – Lost ACK ^\ - Lost NAK in the program. I'm kinda confuse about signals and handling.  Please help, thanks.
Who is Participating?
Signal handler functions receive an integer defining one-of the possible
signals defined in signal.h.   Each of the keystrokes you mention
sends a different signal to the process*.  So your signal handler gets a
value passed to it that corresponds to the keystroke sent:

^C  sends the SIGQUIT, ^Z sends EOF on STDIN, etc.   When you register
your signal handler, you specify a mask representing the set of signals you
will accept.  Your handler should then check which of the signals from that
set it actually received.

man signal

Assuming that we're talking about signals as in "SIGQUIT" etc, rather than things like "end of file" conditions...

Signals are a bit like interrupts - they can happen at any time.
As Brett said, "man signal" will tell you a fair amount, and following the "see also" stuff will tell you more.

Note: Some signals can't be caught and processed by your program, e.g. SIGKILL (the classic "kill -9") kills a process stone dead so fast the process doesn't know what hit it - it just ceases to exist.  SIGSTOP is much the same, only the process gets suspended isntead of dieing.

You've not specified what operating system you're playing with here - more detail would kinda help.

On Solaris "man sigaction" will tell you much about how to intercept these signals - the basic idea is that you write yourself a function, and register that to be called instead of the original signal handler by calling sigaction(...) with various parameters (one of which is the number of the signal you want to over-ride).  Just note that this function can then be called at _any_ point in your program's execution - e.g. halfway through a printf call or whatever.
On Linux it's a bit simpler (friendlier!), e.g.

void someone_just_pressed_ctrl_c(int willBeTwo)
  fprintf(stderr,"It's no use, pressing Ctrl-C won't quit anymore\n");

int main(int argc, char **argv)
  sighandler_t oldHandler = signal(SIGINT,someone_just_pressed_ctrl_c);
  return 0;
Note: It's not necessary to restore the old handler if you're just about to exit anyway, but I thought I'd include it for completeness.

I'm not sure, but there may be things you have to do in your signal handler to ensure the system knows you've finished with it, e.g. tell it to "clear" the signal.  Not sure about that - see the man-pages for the system you're using.
On occasion, you may want your program to wait for a period of time before continuing, giving the affect of a pause. This can be achieved using a sleep function.

To make a standard sleep function that is portable, you can use the following functions, as supplied by Prelude and Sebastiani. These simply put your program into a permanent loop until the necessary amount of time has passed. The problem with this method is that it is very CPU intensive. For a less CPU intensive, but also less portable method, keep reading.

#include <time.h>

void sleep_seconds ( long seconds ) {
  clock_t limit, now = clock();
  limit = now + seconds * CLOCKS_PER_SEC;
  while ( limit > now )
    now = clock();

void sleep_ticks ( long ticks ) {
  clock_t limit, now = clock();
  limit = now + ticks;
  while ( limit > now )
    now = clock();

void wait(long milliseconds)
  long timeout = clock() + milliseconds;
  while( clock() < timeout ) continue;

Some compilers come with a non-standard set of functions to do the same thing, but these normally put your program to sleep without the need for a permanent loop. The advantage with these is that they don't hog the CPU.

Check your compiler's documentation for some of these functions:

Sleep() (maybe in windows.h)
sleep() (maybe in unistd.h)
delay() (maybe in dos.h)

Be warned, some functions work in milliseconds, and some in seconds, so handle with care  
I must say, I've never seen a program (other than on machine with no operating system) use a "busy loop" (i.e. CPU intensive loop)*.
I know such practices aren't uncommon in simple embedded devices and on MSDOS programs where there is no operating system or other programs running, but I'd have expected those to be in the minority these days.

I would seriously recommend the use of sleep() or whatever equivalent your target platform has.  It's not unknown for system administrators to get "quite excited" about people who persist in running such programs, and such people to then find everything they do has somehow been reduced to "minimum priority", hence takes ages to do anything, assuming their files don't accidentally get lost in a highly localised disc-crash incident instead.
If you're running on a standalone PC then it's not so big an issue, but if you're on a shared server, it's best to be nice.

* Actually that's not quite true - I found that Windows 3.1, which was claimed to be an operating system, would use a busy-loop for some internal operations, resulting in the machine locking up for many minutes, sometimes indefinately, before the system returned to normal.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.