Sender class diagram

Sender sequence diagram

Sender state diagrams

Receiver class diagram

Receiver sequence diagrams

From the presentation of the project, many questions were asked by department lecturers, which needed to be resolved, and they were:

• How scalable is PGM?
• What type of network performance do we expect from PGM?
• Will we need some type of simulation, to analyse PGM network performance?

After the discussion with Prof. Jon we came out with the following results:

• The project involves the implementation of the host side, which means that we should not be involved in the network side of PGM. Therefore, the questions of PGM network performance and PGM scalability are beyond the scope of this project.
• No simulation is needed.
• We should test how PGM performs compared to other protocols (i.e., UDP) in terms of CPU speed and memory usage.

• He suggested using CVS, to be able to work collectively on files. All members without loosing information will see creating and updating files.

After the group had conducted some research on PGM and kernel programming many questions came to light, and they are:

• We were not able to find relevant material regarding kernel programming.

• Will we need a sophisticated application for the project to be able to use PGM?
• The groups felt that we needed a crash lecture of how the PGM code would be linked to the kernel and explain the whole picture of the operations involved to be able to send and receive packets by the kernel and pass it to PGM code.

After the discussion with Prof. Jon we came out with the following results:

• He suggested to read "TCP/IP Illustrated", Volume 2., by Richard Steven.
• He sent us the latest copy of the PGM draft, Draft 3.
• There is no need for a sophisticated application is compulsory unless we had time to develop one. He also, suggested that a Ph.D. student might be able to provide us with an application to use to test our PGM code.
• Prof. Jon gave us a brief but detailed lecture of how the kernel will interact with PGM code. Many questions were resolved.

We had the following questions to ask:

• Theory about what we expect from testing.

After the discussion with Prof. Jon, testing should include the following:

• How long will it take to do a task? Choose some functions and test them

• Memory use
• CPU use

We had the following questions to ask:

• In regard to the Receiver, we designed the NAK generation function in a way where at any time only one NAK can be pending, if there was a need to generate another NAK we will have to wait until the pending NAK completes the NAK cycle. The Receiver team saw this approach as inefficient. The question was how can we improve this without being able to use threads –threads can not be used in the kernel.
• In regards to the Receiver, it was unclear from the draft, whether when sending a NAK do we have to send the packet only once containing the multicast address or for every NAK we send one as multicast and another as a unicast.
• In regards to the Receiver, - a technical question – where can we find multicast address.
• In regards to the Sender, it was ambiguous in the draft of how the traffic shaper calculates the window advance rate, in one part of the draft it says that it can be calculated from counting SPMs, ODATA and RDATA. In another place it explains that you count ODATA and RDATA packets, no SPMs where mentioned.

After the discussion with Prof. Jon the Receiver team had to change a major part of their code to make it more efficient according to Prof. Jon’s recommendations. All the other points of concern were resolved.