From 6c6bde3015e787eb077b831d70e9160a87288074 Mon Sep 17 00:00:00 2001 From: Borja Sotomayor Date: Tue, 9 Apr 2024 20:27:15 -0500 Subject: [PATCH] Updated website --- projects/project2.html | 27 +++-- projects/project2_rubric.html | 194 ++++++++++------------------------ 2 files changed, 70 insertions(+), 151 deletions(-) diff --git a/projects/project2.html b/projects/project2.html index 6a239c6..45aac2d 100644 --- a/projects/project2.html +++ b/projects/project2.html @@ -8,7 +8,7 @@ Project 2: chitcp — CMSC 23320 - Foundations of Computer Networks - + @@ -99,10 +99,6 @@

Project 2: chitcp

-
-

Warning

-

This page has not yet been updated for Spring 2024.

-

In this project you will be implementing the Transmission Control Protocol, as specified in [RFC793]. However, instead of implementing it inside the operating system itself, you will be implementing @@ -135,21 +131,21 @@

Submission Timeline

Intermediate Submission

+

Project 2A

Assignment 1 of chiTCP

-

Wednesday, October 26, 8pm

+

Wednesday, April 24, 8pm

-

Final Submission

+

Project 2B

Assignment 2 of chiTCP
(Note: Assignment 2 builds on Assignment 1)
-

Wednesday, November 9, 8pm

+

Wednesday, May 1, 8pm

Resubmission (Optional)

Address feedback received in Project 2

-

One week after Project 2 is graded

+

One week after Project 2B is graded

@@ -163,14 +159,15 @@

Initializing your Project 2 Repository$REPO_URL refers to the SSH URL of your repository. To get this URL, log into GitHub and navigate to your -project repository. Then, click on the green “Code” button, and make sure the -“SSH” tab is selected. Your repository URL should look something like this: -git@github.com:uchicago-cmsc23320-2022-aut/chitcp-p2-jdoe-jrandom.git

+project repository. Then, under “Quick setup — if you’ve done this kind of thing before”, +make sure the “SSH” button is selected, and copy the URL that appears next to it. +It should look something like this: git@github.com:uchicago-cmsc23320-spr-24/chirc-jdoe-jrandom.git

git init
 git remote add origin $REPO_URL
 git remote add upstream https://github.com/uchicago-cs/chitcp.git
-git pull upstream master
-git push -u origin master
+git pull upstream main
+git branch -M main
+git push -u origin main

Cloning instructions

diff --git a/projects/project2_rubric.html b/projects/project2_rubric.html index 17f753f..7eb3379 100644 --- a/projects/project2_rubric.html +++ b/projects/project2_rubric.html @@ -8,7 +8,7 @@ Project 2 Rubric — CMSC 23320 - Foundations of Computer Networks - + @@ -103,21 +103,20 @@
  • Code Quality
  • Correctness
  • Design
  • Style
  • Other Code Quality Issues
    • -
  • Optional Resubmission
    • @@ -126,13 +125,11 @@

    Project 2 Rubric

    -
    -

    Warning

    -

    This page has not yet been updated for Spring 2024.

    -

    The grading of this project follows a specifications grading approach. If you have not already -done so, make sure to read our Grading page for more details.

    -

    You will receive two ESNU scores for this project:

    +done so, make sure to read our Grading section of +the syllabus for more details.

    +

    This project has two submissions: Project 2A and Project 2B. You will receive two SNU scores +for each submission:

    Completeness

    @@ -207,8 +195,7 @@

    CompletenessAutomated tests in the chiTCP documentation and, specifically, the “Producing a grade report” section for more details)

    -

    Your ESNU score will then be determined as follows, using the sum of the test scores -in Assignments 1 and 2:

    +

    Your SNU score will then be determined as follows:

    @@ -216,17 +203,14 @@

    Completeness

    - - - - + + - - + + - - + +

    Grade

    Excellent

    at least 95

    Satisfactory

    at least 80

    Satisfactory

    at least 90

    Needs Improvement

    at least 25

    Needs Improvement

    at least 60

    Ungradable

    less than 25

    Unsatisfactory

    less than 60
    @@ -236,18 +220,16 @@

    Code Quality -

  • Excellent: Your submission has none of the issues described below or, at most, -has only a few minor mistakes or small style issues that would be trivial to address.

  • Satisfactory: Your submission has a few of the issues described below (but no -major issues), and would only require minor changes to get to an E.

    • +major issues).

  • Needs Improvement: Your submission has several of the issues described below, -or at least one major issue. In general, major revisions would be required to -get up to an S or E.

    • -

  • Ungradable: Your submission does not constitute a good-faith effort to complete +or at least one major issue. In general, major revisions are typically required to +get up to an S.

    • +

  • Unsatisfactory: Your submission does not constitute a good-faith effort to complete the work. This includes not submitting any work at all, as well as submitting only placeholder code (e.g., code that includes functions for all the required IRC commands, but where the functions are empty or filled with “TODO”s, etc.)

    • @@ -275,16 +257,17 @@

    General

  • Not locking the pending packets mutex before accessing the pending packets list.

    • -
    -

    [Assignment 1] 3-way Handshake

    +
    +

    [Project 2A] 3-way Handshake

    • Not acknowledging the final ACK in the 3-way handshake. Remember that acknowledgements are not acknowledged in TCP.

    • Not checking that the SYN was acknowledged before sending the ACK and changing state to ESTABLISHED.

      • +

    • 3-way Handshake: Setting the ISS to a constant value, instead of using a random number.

    • [Major issue] Writing a 3-way handshake by rote that doesn’t check the TCP header values, and assumes that the first three messages exchanged must be a SYN, SYN/ACK, and ACK. For example, you could technically pass the three-way handshake tests by making TCP go into an ESTABLISHED state after receiving two packets (without checking whether the first one is a SYN packet, and whether the second one contains a valid ACK).

    -
    -

    [Assignment 1] Data Transfer

    +
    +

    [Project 2A] Data Transfer

    • Not checking if the value of SEG.ACK and SEG.SEQ is correct. In some cases, no action needs to be taken when a value is incorrect, but we still recommend (but not require) that you chilog() any such cases.

    • Not setting the ACK flag and including a valid acknowledgement number in every packet after the 3-way handshake. Remember that, even if you haven’t received any new data, you still have to send a valid acknowledgement number in every segment.

      • @@ -295,25 +278,25 @@

      [Assignment 1] Data Transfer -

      [Assignment 1] Connection teardown

      +
      +

      [Project 2A] Connection teardown

      • Not handling the APPLICATION_CLOSE event in both ESTABLISHED and CLOSE_WAIT. In both cases, you should only send a FIN packet if there is no data left in the send buffer, but you should transition to FIN-WAIT-1 / LAST-ACK (respectively) right away.

      • Not delaying the FIN packet until all outstanding data has been sent and acknowledged.

      • Not handling the APPLICATION_RECEIVE event in FIN_WAIT_1 and FIN_WAIT_2. TCP can still receive data in those states, which means the application may still call recv.

      -
      -

      [Assignment 2] Managing the Retransmission Queue

      +
      +

      [Project 2B] Managing the Retransmission Queue

      • Adding pure ACK packets (i.e., not SYN or FIN segments, nor segments with a payload) to the retransmission queue. ACK packets are not retransmitted.

      • Adding segments with a payload to the retransmission queue, but not adding SYN or FIN segments

      • Not removing acknowledged packets from the retransmission queue. Take into account that multiple packets could be removed because of a cumulative ack. However, you should not automatically remove all the packets from the retransmission queue whenever you receive an ACK, because you could have packets 1-10 in the queue, and receive an acknowledgement only for 1-5.

        • -

      • Locking the retransmission queue. The retransmission queue is only ever accessed by the socket thread, so there is no possibility of concurrent access by multiple threads. So, it does not need to be protected by a mutex.

        • +

      • Unnecessarily locking the retransmission queue. The retransmission queue is only ever accessed by the socket thread, so there is no possibility of concurrent access by multiple threads. So, it does not need to be protected by a mutex.

      -
      -

      [Assignment 2] Managing the Timer Thread

      +
      +

      [Project 2B] Managing the Timer Thread

      • Unconditionally setting the timer every time a packet is sent. You should set the timer only if you are sending a packet with data (or a SYN or FIN) and the timer is not already active. If the timer is already active, then sending new data doesn’t affect the timer in any way.

      • Not cancelling the timer when all outstanding data has been acknowledged

        • @@ -321,30 +304,30 @@

        [Assignment 2] Managing the Timer Thread -

        [Assignment 2] Handling the retransmission timeout

        +
        +

        [Project 2B] Handling the retransmission timeout

        • Not doing Go-back-N. When a TIMEOUT event happens, you should be doing go-back-N: find the earliest unacknowledged segment in the retransmission queue, and retransmit that segment and all subsequent segments. It is not enough to only retransmit the first segment (without checking whether there are subsequent packets)

        • Not backing off the RTO each time a timeout happens.

        -
        -

        [Assignment 2] RTT estimation

        +
        +

        [Project 2B] RTT estimation

        • [Major issue] Not doing any RTT estimation. The RTT estimation tests can’t check whether you implemented RTT estimation correctly (at most, they may alert you to failures that arise as a result of an incorrect RTT estimation), so the graders will be manually checking that you implemented RTT estimation correctly.

        • Doing RTT estimation, but making a minor mistake in computing the RTT

        • Doing RTT estimation, but not excluding retransmitted segments from the RTT estimation

        -
        -

        [Assignment 2] Persist timer

        +
        +

        [Project 2B] Persist timer

        • Did not actually implement the persist timer. (this rubric item is only applied if you are somehow passing all the persist timer tests, despite not implementing the persist timer)

        • Not updating SND.NXT when sending a probe segment.

        -
        -

        [Assignment 2] Out-of-order

        +
        +

        [Project 2B] Out-of-order

        • Did not actually implement out-of-order delivery. (this rubric item is only applied if you are somehow passing all out-of-order tests, despite not implementing out-of-order delivery)

        • Not placing out-of-order segments in the out-of-order list

          • @@ -443,67 +426,6 @@

          Other Code Quality Issues -

          Optional Resubmission

          -

          When you receive your graded Project 2, you have two options:

          -
            -

          1. If you are satisfied with the scores you have received, no action is necessary on your end. -Your scores on Project 2 will be used to compute your Base Grade.

            2. -

          2. You may make an optional resubmission to address any feedback you received in Project 2, -which may increase your scores in the project.

            3. -
          -

          Note: You cannot make a resubmission if you got E’s on both Completeness and Code Quality. If you -are in this situation and want additional feedback on your grading, please ask on Ed.

          -

          If you decide to make a resubmission, you MUST edit the README file in the root of -the repository to include the following information:

          -
            -

          • Rubric items you have addressed: Rubric items that appear selected on Gradescope (under “Manual Grading”) -represent issues that had an impact on your Code Quality score. To facilitate the work of the -graders, you must list each rubric item you have addressed, with the following information:

            -
              -

            • The rubric item description, exactly as it appears on Gradescope.

              • -

            • 1-2 sentences explaining how you addressed the rubric item.

              • -

            • If the work you did on the rubric item is limited to a few lines of code, specify the filename and line number(s), -If your work on this rubric item involved deeper changes to your code, you do not need to list every single line -of code you changed, but you should try to give the graders a general sense of where you made the changes, including -a few examples if possible -(e.g., “I combed through the code to make sure I was using descriptive variable names; for example, I changed c to -channel in several functions”, “I reorganized functions foo(), bar(), and baz() as requested”, etc.)

              • -
            -
            • -

          • Rubric items you have NOT addressed: It is also important that you let us know what rubric items you -decided not to address, as this will expedite the work of the graders. For these rubric items, it is enough -to provide a list of the rubric item descriptions (exactly as they appear on Gradescope)

            • -

          • Substantial new code added to your submission: If you added substantial new code that was not present in your -original submission (e.g., if your original submission did not implement certain features, and you have now included -new code to implement those features), you must specify the functions you added or modified in either tcp.c or multitimer.c. For example you could include something like this:

            -
            Modified function: handle_packet_arrival (tcp.c)
-New functions: add_to_out_of_order, process_out_of_order (tcp.c)
-
-Our original submission did not implement out-of-order delivery,
-but we implemented it in the above functions.
-
            -
            -
            • -

          • Changes made to pass additional tests: If you made changes to your code with the goal of passing more tests, -please specify your original test score, and the new test score. If your work only involved a few minor bug fixes, -please let us know you did this (but you do not need to specify the exact changes you made). On the other hand, -if you skipped parts of Assignment 2 in your original submission, and have written entirely new code, please make -sure you have specified this as part of the “substantial new code”, and that you also specify that doing so -allowed you to pass additional tests.

            • -

          • Other changes: If you made other changes to your code, such as refactoring large parts of your code, make -sure to specify this too.

            • -
          -

          You should consider the README file as important as the changes you are making to your code: resubmissions -that do not include the information requested above may not be graded at all.

          -

          In general, if you are making a resubmission that only involved addressing rubric items, without adding substantial -new code to your submission, there is a high likelihood that addressing all the rubric items will bump your Code -Quality score to at least the next score.

          -

          On the other hand, if you are making a resubmission that involves adding substantial new code, please bear in mind -that the graders could identify issues in that new code that will impact your Code Quality score. That said, -once you receive the resubmission grading, you will be given the option to revert back to your original Project 2 -score if you prefer.