[an error occurred while processing this directive]
Try to ping your box from the Unix machine. If it replies, the
stack is still running, otherwise it is deadlocked.
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
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.
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
[00-08-26, revised 01-07-30]
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
[ 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
[00-08-04, revised 01-07-30]