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.
- 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
- 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
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
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.
- When compiling echo.c I get
error messages from the linker (undefined references to
When linking on Solaris you'll need to specify explicitly that
you're using the sockets library via the -lsocket
argument. Apologies for not pointing that out (it works without
that argument on Tru64 and Linux).
- 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.
[ 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
School of Computer Science and Engineering,
University of New South Wales
This page is maintained by
Last modified: Wednesday, 30-Aug-2000 19:17:49 EST