Answers to
Frequently Asked Questions About the Project

• I get a few packets from the network, and then nothing.

  Try to ping your box from the Unix machine. If it replies, the stack is still running, otherwise it is deadlocked.
  [00-08-30]

• I found that it seems to declare 1MB of memory just after the DIT in memory, which is fine, but it broke mine (and a couple of other) people's pagers because that's where we store our frame tables. Just thought you might want to consider letting people know, though if you want them to debug for a couple of hours like me, I understand ;)

  Good point. Although, I hate to tell you, if this is a problem for your OS then it's bad code.

  You need to claim memory, without making assumptions on what is free and what isn't (other than the kernel reserved areas, of course, which you aren't to touch).

  Also, it is important to avoid race conditions, so you need to give the drivers the chance to claim whatever memory they need. The safest way to do that is by not claiming any free RAM until you had your first communication with the driver, thus establishing that it's up and running.
  [00-08-28]

• Given that UDP is unreliable, do we have to implement a reliable network protocol (like TCP, 3 way handshakes and sliding window to handle packets reordering/deplicate, stop/wait)?

  You will have to deal with the unreliability of UDP, but you shouldn't go overboard. Implementing proper NW protocols isn't the objective of this course, we have a range of networking courses which deal with such issues.

  So, one (acceptable, but barely ;-) algorithm would be to acknowledge each packet individually, and not send the next packet until the previous one has been acknowledged, or timed out. Obviously you'll get fairly poor network throughput that way.

  However, it is perfectly acceptable to make use of the features of your particular environment. Among others, this means that UDP will be "mostly" reliable, i.e., the network will rarely drop packets, and it will generally deliver them in FIFO order, and will do so within a very predictable time interval.

  Based on this you can implement a very simple algorithm which sends a sequence of packets and acknowledges the whole sequence. You can experiment with timings to see how fast you can send packets reasonably reliably.

  Whatever you do, document it!

  And remember: Make it work, before making it fancy! I strongly recommend to implement the slow acknowledge-packets-one-at-a-time protocol first, so you've got something to build on.
  [00-08-27]

• When compiling echo.c I get error messages from the linker (undefined references to socket etc).

  This is a problem that may occur on Solaris. As you are working on Linux boxes, you should not get it, but I've left this in just in case...

  When linking on Solaris you'll need to specify explicitly that you're using the sockets library via the -lsocket argument.
  [00-08-26, revised 01-07-30]

• Why do I sometimes get funny results when I make my print buffers large?

  You're overflowing your stack. The print buffer in the example is allocated as a local ("automatic") variable on the stack. The stack is only 1kb big. So, what happens if you put a 4kb buffer on the stack? You guessed it: evil things happen.

  Cure: declare the buffer "static" and it won't be on the stack. However, this also means that concurrent calls to printf() will clobber the buffer unless you use concurrency control!

  [ It could be argued that the code I gave you shouldn't have the buffer on the stack in the first place.

  It could also be argued that it's better if you get bitten by this now :-]
  [00-08-04, revised 01-07-30]