FAQ Categories
Why does miniport_remote_create take an id when there is already an id in the addr parameter?
The id in the addr parameter is the physical port used for communication by network.c to emulate the IP layer. You must specify an id for the remote port in miniport_remote_create.
Local ports and remote ports need to contain different kinds of information and yet they are both supposed to have type struct miniport.
Use a C's union capability. If you have an enum to track LOCAL/REMOTE ports, you then know which part of the union to access.
This is superior to setting dummy variables as it does not waste space.
Why should I include the sender's network address in the header of each message if I can take this information from the parameter given to the network handler?.
Your implementation of unreliable communication will be used throughout the entire semester. In the Project 5 you will need to implement an Ad-hoc networking in which a packet should pass through a chain of computers. To apply Ad-hoc routing policies you will need the address of the source of the packet.
We need to implement miniport_remote_create function. When must applications use this function ?.
When application A sends a remote message to application B, minimsg_send needs to know the port on which B listens (B's local port). That's why application A creates a remote port that is bound to the B's local port (see network[5-6].c examples). The minimsg_receive creates the remote port bound to the sender, not the application that uses the function. You should use miniport_remote_create function inside minimsg_receive function and store in the "remote" parameter the structure assigned to the remote port.
How can I safely signal a semaphore from both in threads threads and the interrupt handlers?
Semaphores may be used within interrupt handlers, but care must be taken to avoid race conditions (afterall, what happens if the semaphore's TAS lock is held by the thread that was just interrupted?). Particularly, we want a means of signaling threads to wakeup from within the interrupt handler, without encountering any form of deadlock.
The following pseudocode shows a good pattern to use outside of interrupt handlers when you must use a semaphore that will also be signaled (semaphore_V) within interrupt handlers:
old = set_interrupt_level(DISABLED) do_stuff() semaphore_P(sem) do_more_stuff() set_interrupt_level(old)This will ensure do_stuff() and semaphore_P are atomic and execute together. It cannot guarantee that interrupts will be enabled on return from semaphore_P (if P blocks, then interrupts will be enabled on context switch). If do_more_stuff() needs to run with interrupts disabled, you must reset the interrupt level, and then re-disable it.
It's important to note that any semaphore manipulated in the interrupt handler should be protected in this fashion everywhere else it is used.
Note
This is not the way to synchronize with the interrupt handler. You should be only using semaphores within the interrupt handler for signaling purposes.
How do I provide mutual exclusion on structures that are used in the interrupt handler and in my thread code?
The safest way to do this is disabling of interrupts.
I don't see my packets being received. What's wrong? Is the network handler not being delivered.
Check that you aren't creating a deadlock situation. Most of the time this symptom (no interrupts) is not the cause, but a side effect.
Do we need to free the network_interrupt_arg_t passed to our network handler?
Yes. The interrupt delivery mechanism allocates a new buffer for each packet. Imagine if the OS you used leaked memory every time it got a network packet. Streaming video and other high-bandwidth applications would cause your kernel to bloat very fast.
These tests fail in some way (e.g., network_send_pkt fails, or the packets never make it). What's wrong?
First, check that you can ping from one machine to another (to establish that there is a route between them).
Check your firewall settings to see if minithreads is denied from sending packets.