[ This content is protected and may not be shared, uploaded, or distributed. ]

(Please also check out PA5 FAQ.)

Lab 12 has two parts:

Part A (lab12a) - forwarding table (useful for PA5):

Our node will act more like a router in this lab. (Although in Lab 11, it already perform flooding, which is a router function.) We will continue with Part A of your Lab 11 code and add the following "forwarding" console command:
Name     Arguments     Description
forwarding   (Please ignore additional arguments if they are present.) List the forwarding table of the node whose console you are typing into (let's call this node SELF). If SELF can route to K other nodes (according to its adjacency list) whose NodeIDs are NodeID_1, NodeID_2, ..., NodeID_K and the NodeIDs of the next-hop (i.e., active neighbor) to reach these nodes are NodeID_NH1, NodeID_NH2, ..., NodeID_NHK, respectively, you must print the following to the console (please note that a node cannot route to itself): 
        NodeID_1: NodeID_NH1\n
        NodeID_2: NodeID_NH2\n
        ...\n
        NodeID_K: NodeID_NHK\n
If SELF does not have active neighbors or if its adjacency list only contains information about itself, you must print the following to the console: 
        SELF has an empty forwarding table\n
Before you print the forwarding table, you must run BFS to clean up the adjacency list since there may be unreachable nodes in your adjacency list data structure.

At the end of Lab 11, every node in the same partition has the same adjacent list. Let's say that you are node X, once you have an adjacent list, you can simply run BFS to construct a shortest path tree (SPT) rooted at node X. When the BFS algorithm in Lab 2 terminates, all nodes except for node X has a "predecessor" pointer ("pred") that points toward to the root of the SPT, which is node X in this case. If you reverse all these "predecessor" pointers, you would end up with a forwarding tree that tells you how to deliver a message from node X to any other node in 353NET along the SPT.

For example, if the network topology looks like the following: 

                       +-------+
                    /--+ 12010 +--------------------------\
                    |  +-------+                          |
                    |                                     |
    +-------+   +---+---+     +-------+   +-------+   +---+---+
    | 12000 +---+ 12002 +-----+ 12004 +---+ 12006 +---+ 12008 |
    +-------+   +---+---+     +---+---+   +-------+   +-------+
                    |             |
                    |  +-------+  |
                    \--+ 12012 +--/
                       +-------+
and you are at node :12000 (we will refer to this node as SELF), after you run BFS with SELF as the root of the SPT, it would look like the following (some edges are removed so it looks like an inverted tree): 
                       +-------+
                    /--+ 12010 +<-------------------------\
                    |  +-------+                          |
                    v                                     |
    +-------+   +---+---+     +-------+   +-------+   +---+---+
    | 12000 +<--+ 12002 +<----+ 12004 +<--+ 12006 +   + 12008 |
    +-------+   +---+---+     +---+---+   +-------+   +-------+
                    ^           
                    |  +-------+
                    \--+ 12012 +
                       +-------+
The arrows above are the pred pointers in the BFS pseudo-code . If you reverse all the arrows, it would look like the following: 
                       +-------+
                    /->+ 12010 +--------------------------\
                    |  +-------+                          |
                    |                                     v
    +-------+   +---+---+     +-------+   +-------+   +---+---+
    | 12000 +-->+ 12002 +---->+ 12004 +-->+ 12006 +   + 12008 |
    +-------+   +---+---+     +---+---+   +-------+   +-------+
                    |           
                    |  +-------+
                    \->+ 12012 +
                       +-------+
The above would be the SPT rooted at node :12000. But how can you reverse the arrows if there is only one pred pointer in each node of the graph? So, we can only reverse the arrows conceptually. The goal is to find, for each node Y in the graph, the first hop SELF must take to reach Y, in the SPT rooted at SELF. What you can do is to start at node Y and follow the pred pointer. If a pred pointer points to SELF, then you have found the first hop neighbor of SELF in the SPT rooted at SELF. So, for each node Y in the forwarding table, the first-hop neighbor to reach Y can be obtained using the following pseudo-code: 
    while (Y.pred != SELF) Y = Y.pred
    return Y

The forwarding table at node X is a list of KEY: VALUE pairs where KEY is a destination node ID and VALUE is the first hop active neighbor of node X on node X's SPT, rooted at node X. (Each node only has to compute only one SPT and that's the SPT rooted at the node itself.) If X is node :12000, then the forwarding table at node X is: 

    :12002: :12002
    :12004: :12002
    :12006: :12002
    :12008: :12002
    :12010: :12002
    :12012: :12002
i.e., to send a message to any node from node X, the first hop should take you to :12002. If you look at the example network topology, this result seems fairly intuitive!

We will use a set of slightly different configuration files from what's used in Lab 11. Please do the following:

  • Create an empty directory (call it "lab12") and change directory into it.
  • Download lab12data.tar.gz into that directory and type: 
        tar xvf lab12data.tar.gz
    This should create a subdirectory called "lab12data" with several .ini files in it which we will use as configuration files for our nodes.
The usage information (i.e., commandline syntax) for "lab12a" is as follows: 
    lab12a CONFIGFILE
where CONFIGFILE is similar to the ones that was used in Lab 11. The only difference is about what messages you must log to the logfile and cout. For this part of the lab, you no longer need to log LSUPDATE messages to cout (although you could if you would prefer). A new type of message called the UCASTAPP message (used in Part B below) must be logged to cout.

When you are done with implementing lab12a, please do the following:

  • Change directory into the "lab12" directory mentioned above.
  • Open 4 Terminals and change directory into the same directory.
  • In the first Terminal window, type "script lab12a-12000.script" to start a transcript.
  • In the 2nd Terminal window, type "script lab12a-12002.script" to start another transcript.
  • In the 3rd Terminal window, type "script lab12a-12004.script" to start another transcript.
  • In the 4th Terminal window, type "script lab12a-12012.script" to start another transcript.
  • In the first Terminal window, type: 
        uname -a
    cat /etc/os-release
    make clean
    make lab12a
    ./lab12a lab12data/lab12-12000.ini
  • In the 2nd Terminal window, type "./lab12a lab12data/lab12-12002.ini".
  • In the 3rd Terminal window, type "./lab12a lab12data/lab12-12004.ini".
  • In the 4th Terminal window, type "./lab12a lab12data/lab12-12012.ini".
  • The network should look like the following: 
        +-------+   +-------+     +-------+
    | 12000 +---+ 12002 +-----+ 12004 |
    +-------+   +---+---+     +---+---+
                    |             |
                    |  +-------+  |
                    \--+ 12012 +--/
                       +-------+
  • Type "netgraph" in all four windows and make sure that every node agrees that the above is the network graph.
  • Type "forwarding" in the 1st window and you should see (order doesn't matter): 
        :12002: :12002
    :12004: :12002
    :12012: :12002
    The above is saying that, for :12000, the next-hop to all other three nodes is :12002. This should make intuitive sense from the above network graph.

  • Type "forwarding" in the 2nd window and you should see (order doesn't matter): 
        :12000: :12000
    :12004: :12004
    :12012: :12012
    The above is saying that, for :12002, the next-hop to :12000 is :12000, to :12004 is :12004, and to :12012 is :12012. This should also make intuitive sense from the above network graph.

  • Type "forwarding" in the 3rd window and you should see (order doesn't matter): 
        :12000: :12002
    :12002: :12002
    :12012: :12012
    The above is saying that, for :12004, the next-hop to both :12000 and :12002 is :12002, and the next-hop to :12012 is :12012. This should also make intuitive sense from the above network graph.

  • Type "forwarding" in the 4th window and you should see (order doesn't matter): 
        :12000: :12002
    :12002: :12002
    :12004: :12004
    The above is saying that, for :12012, the next-hop to both :12000 and :12002 is :12002, and the next-hop to :12004 is :12004. This should also make intuitive sense from the above network graph.

  • Type "quit" in the 2nd window and :12002 should self-terminate.
  • Type "forwarding" in the 1st window and you should see: 
        :12000 has an empty forwarding table
  • Type "forwarding" in the 3rd window and you should see: 
        :12012: :12012
  • Type "forwarding" in the 4th window and you should see (order doesn't matter): 
        :12004: :12004
  • In the 2nd Terminal window, type "./lab12a lab12data/lab12-12002.ini" to restart :12002.
  • Type "forwarding" in all four windows and make sure you see the correct forwarding tables.
  • Type "quit" in the 1st window and :12000 should self-terminate.
  • Type "forwarding" in the 2nd window and you should see: 
        :12004: :12004
    :12012: :12012
  • Type "forwarding" in the 3rd window and you should see: 
        :12002: :12002
    :12012: :12012
  • Type "forwarding" in the 4th window and you should see: 
        :12002: :12002
    :12004: :12004
  • Type "quit" in all the remaining window.
  • In the 4th Terminal window, type the follow to display all the log files (to see that SAYHELLO and LSUPDATE messages are properly logged): 
        more lab12data/*.log
  • Type "exit" in all four windows to close the transcripts.
To save typing all some of the commands above, a tmux script, "tmux-lab12a.txt" is provided in the "lab12data" directory created above and you can run it by typing: 
    lab12data/tmux-lab12a.txt
Plesae note that it's provided for your convenience (i.e., to save typing) and it may not be exactly the same as the above sequence. Please see PA2 FAQ regarding how to use tmux in general.

Part B (lab12b) - message routing and udt (useful for PA5):

In this lab, we will impmlement layer 4 (transport layer) functionalities in the 353NET. We will start with your Part A code and add support for a new type of message, UCASTAPP, so that networking application can exchange messages with each other on top of 353NET. UCASTAPP stands for "unicast application" to mean that it's a message from a source node, to be delivered to a destination node. (In networking, there are also other "casts". For example, "broadcast" means to deliver message to all nodes in the network. There is also something called "multicast" where one message needs to be delivered to multiple nodes. There is also something called "anycast" where one message needs to be delivered to one out of a list of nodes.) When a source node sends a UCASTAPP message to a destination node, it has no idea whether the destination node has received the message or not. In a way, this is similar to sending a UDP message in the Internet.

A UCASTAPP message looks like the following:

Unicast Application Message (MSGTYPE: UCASTAPP) :
     An UCASTAPP message header, followed by an empty line, must look like the following: 
        353NET/1.0 UCASTAPP\r\n
        TTL: NUMBER\r\n
        Flood: 0\r\n
        MessageID: MSGID\r\n
        From: SRC_NODEID\r\n
        To: DEST_NODEID\r\n
        Next-Layer: NEXT_LAYER\r\n
        Content-Length: LENGTH\r\n
        \r\n
where NUMBER is an integer. For the node that initiated this message, MSGID must be a freshly created MessageID. SRC_NODEID is the NodeID of the node that initiated this message. DEST_NODEID is the NodeID of the node that this message is trying to reach (i.e., the target node). NEXT_LAYER is for demultiplexing and it can be either 1 (for "udt", i.e., unreliable data transfer) or 2 (for "rdt" in Lab 14, i.e., reliable data transfer). LENGTH is the number of bytes in the message body, which immediately follows the empty line after the message header.

Please note that LENGTH is a byte count. If the message body is supposed to be an ASCII string, LENGTH would be the string length of the ASCII string, i.e., you must not send a trailing null character (i.e., '\0'). If you don't handle LENGTH properly in your code, you will not be able to detect message boundary correctly. So, it's very important to implement this correctly.

For a UCASTAPP message, LENGTH must be ≤ 1024.

A unicast message (UCASTAPP) needs to be routed. At each node, message routing is done using the forwarding table you have implemented in Part A of this lab. Let's take a look at an example.

If the topology of the network looks like the following (same as the example above): 

                       +-------+
                    /--+ 12010 +--------------------------\
                    |  +-------+                          |
                    |                                     |
    +-------+   +---+---+     +-------+   +-------+   +---+---+
    | 12000 +---+ 12002 +-----+ 12004 +---+ 12006 +---+ 12008 |
    +-------+   +---+---+     +---+---+   +-------+   +-------+
                    |             |
                    |  +-------+  |
                    \--+ 12012 +--/
                       +-------+
Let's say that you are at node :12000 and you want to send a UCASTAPP message to node :12008, how would you do it? The answer is pretty simple, you look at your forwarding table and find the entry whose KEY is :12008. The corresponding VALUE is the neighbor to which you must send your message. You must trust that this neighbor will deliver your UCASTAPP message for you and route it to the destination node. In this case, every KEY in the forwarding table for node :12000 has :12002 as its VALUE. So, you must forward this UCASTAPP message to node :12002. In this example, the TTL you must put inside the UCASTAPP message must be the max_ttl value from your node's configuration file.

When the UCASTAPP message reaches node :12002, what should node :12002 do? Firstly, you must check if the current node is the DEST_NODEID in the message. If it is, you should deliver the UCASTAPP message to the next layer (i.e., application layer) according to the NEXT_LAYER value in the message. For this lab, since we don't have the next layer implemented (i.e., no 353NET application yet), you must print the following in the console: 

    No receiver for NL message 'UDTMSGBODY' from SRC_NODEID.
where NL is either "UDT" (if NEXT_LAYER in the message is 1) or "RDT" (if NEXT_LAYER in the message is 2), UDTMSGBODY is the message body of the UCASTAPP message (exactly LENGTH bytes of data), and SRC_NODEID is the SRC_NODEID in the message. The message body of a UCASTAPP message is an "UDT message" for the "next layer" (i.e., application layer). For this lab, a UDT message is simply a test message which is a line of text without any structure and not containing characters such as "\r", "\n", and "\0". We will introduce structures into UDT messages for 353NET applications in the next two labs.

If the current node is not the DEST_NODEID in the message, this node must help to route the message to DEST_NODEID. In this case, node :12002 must decrement the TTL field in the UCASTAPP message and see if it's equal to 0. If it's equal to 0, then routing has failed and this node just drop the message. Otherwise, it must use its forwarding table to forward the message. Before using its forwarding table, it should run BFS in case there are unreachable nodes.

Should you use the message cache to see if this is a duplicate message? You don't have to. But since this message has a MSGID, you can cache it and use it if you'd like. (The worst that can happen is that if you have a routing loop in the 353NET, your message may go around the loop a few times. But it will die soon when TTL reaches 0. Since this type of message is not flooded, it cannot do too much damage.)

Node :12002 has 4 active neighbors. Therefore, you have only 4 choices for the VALUE part of an forwarding table entry. Anyway, the forwarding table for :12002 should look like the following: 

    :12000: :12000
    :12004: :12004
    :12006: :12004
    :12008: :12010
    :12010: :12010
    :12012: :12012
Since the destination for the UCASTAPP message is :12008, according to the above forwarding table, you must forward this UCASTAPP message to node :12010.

When the UCASTAPP message (with a decremented TTL) reaches node :12010, node :12010 must follow the routing protocol. In this example, since :12010 is not the destination node, it must decrement the TTL in the message, and forward the message. In this example, node :12010 has 2 active neighbors (i.e., :12002 and :12008). Therefore, you have only 2 choices for the VALUE part of an forwarding table entry. The forwarding table for :12010 should look like the following: 

    :12000: :12002
    :12002: :12002
    :12004: :12002
    :12006: :12008
    :12008: :12008
    :12012: :12002
Since the destination for the UCASTAPP message is :12008, according to the above forwarding table, you must forward this UCASTAPP message to node :12008.

When the UCASTAPP message (with a decremented TTL) reaches node :12008, node :12008 should see that it's the destination and print the following (since we haven't implemented any 353NET "applications"): 

    No receiver for NL message 'UDTMSGBODY' from :12000.
where NL is either "UDT" (if NEXT_LAYER in the message is 1) or "RDT" (if NEXT_LAYER in the message is 2) and UDTMSGBODY is the message body of the UCASTAPP message.

Please note that before you use the forwarding table to route a message, you need to make sure that the forwarding table is consistent with the adjacency list (since the adjacency list may have changed when an LSUPDATE message was received). If the adjacency list is dirty, then you don't know if the forwarding table is consistent with the adjacency list or not and you need to run BFS and recompute your forwarding table.

Please make a copy of your "lab12a.cpp" and call it "lab12b.cpp" and add another target in the Makefile so that when you type "make lab12b", an executable called lab12b will be created. The usage information (i.e., commandline syntax) for "lab12b" is as follows: 

    lab12b CONFIGFILE
where CONFIGFILE is a configuration file used in Part A of this lab.

You will also need to handle a new console command:

Name     Arguments     Description
udtsend target message Create an UCASTAPP message with the current node's NodeID as the SRC_NODEID, target as the DEST_NODEID, 1 as NEXT_LAYER, and message as the message body, then route this message to target.

Before running this command, you must run BFS to clean up the adjacency list since there may be unreachable nodes in your adjacency list data structure. If target is not in the adjancey list, you must print the following to the console: 

    target is not reachable\n
If target is the NodeID of the node whose console you are typing into. You must print the following to the console: 
    Cannot use udtsend command to send message to yourself.\n
I would recommend that you write a function called udt_send() to initiate a UCASTAPP message with a UDT payload and start sending it towards the destination node using current node's fowarding table (udt_send() was mentioned on slide 4 of the lecture slides on section (3.4) of the textbook on the principles of reliable data transfer). Then call this function when the user enters the udtsend console command. Doing it this way will make things easier for Lab 14 since Lab 14 also follows section (3.4) of the textbook.

In order to be able to see what's going on, you must log UCASTAPP messages to cout (since the value of the UCASTAPP key in the [logging] section of the CONFIGFILE is 0): Recall that the general format for a log entry looks like the following: 

    [TIMESTAMP] {r|i|d|f} MSGTYPE NEIGHBOR TTL FLOOD CONTENT_LENGTH msg-dependent-data\n
If a UCASTAPP messages was initiated, you must use "i" in the 2nd field above. If a UCASTAPP messages was received, you must use "r" in the 2nd field above. If a UCASTAPP messages was sent due to message routing / message forwarding (i.e., received, TTL decremented, and sent), you must use "f" in the 2nd field above (to mean "forwarded").

For a UCASTAPP message, the "msg-dependent-data" must look like the following: 

    MSGID SRC_NODEID DEST_NODEID NEXT_LAYER UDTMSGBODY
where UDTMSGBODY is the message body of the UCASTAPP message (exactly LENGTH bytes of data) and all other fields are from the UCASTAPP message specification. As you can see, a line of log message is getting really long. You might want to consider using the short format when logging a TIMESTAMP and using the short format when logging a MSGID.

When you are done with implementing lab12b, please do the following:

  • Change directory into the "lab12" directory mentioned above.
  • Open three more Terminals and change directory into the same directory.
  • In the first Terminal window, type "script lab12b-12000.script" to start a transcript.
  • In the 2nd Terminal window, type "script lab12b-12002.script" to start another transcript.
  • In the 3rd Terminal window, type "script lab12b-12004.script" to start another transcript.
  • In the 4th Terminal window, type "script lab12b-12012.script" to start another transcript.
  • In the first Terminal window, type: 
        uname -a
    cat /etc/os-release
    make clean
    make lab12b
    ./lab12b lab12data/lab12-12000.ini
  • In the 2nd Terminal window, type "./lab12b lab12data/lab12-12002.ini".
  • In the 3rd Terminal window, type "./lab12b lab12data/lab12-12004.ini".
  • In the 4th Terminal window, type "./lab12b lab12data/lab12-12012.ini".
  • The network should look like the following: 
        +-------+   +-------+     +-------+
    | 12000 +---+ 12002 +-----+ 12004 |
    +-------+   +---+---+     +---+---+
                    |             |
                    |  +-------+  |
                    \--+ 12012 +--/
                       +-------+
  • Type "netgraph" in all four windows and make sure that every node agrees that the above is the network graph.
  • Type "forwarding" in all four windows and make sure that every node has the correct forwarding table.
  • Type "udtsend :12004 hello" in the 1st window and you should see the following in the 1st window: 
        [TIMESTAMP] i UCASTAPP :12002 9 - 5 MSGID1 :12000 :12004 1 hello
    where TIMESTAMP and MSGID1 would depend on the actual value of the timestamp and message ID.

  • In the 2nd window and you should see the following when the UCASTAPP message is forwarded: 
        [TIMESTAMP] r UCASTAPP :12000 9 - 5 MSGID1 :12000 :12004 1 hello
    [TIMESTAMP] f UCASTAPP :12004 8 - 5 MSGID1 :12000 :12004 1 hello
    where MSGID1 must be identical to the MSGID1 in the 1st window.

  • In the 3rd window and you should see the following when the UCASTAPP message is received (order doesn't matter): 
        [TIMESTAMP] r UCASTAPP :12002 8 - 5 MSGID1 :12000 :12004 1 hello
    No receiver for UDT message 'hello' from :12000.
    where MSGID1 must be identical to the MSGID1 in the 1st window.

  • Type "quit" in the 2nd window, :12002 should self-terminate and the network should be partitioned.
  • Type "udtsend :12000 how are you?" in the 1st window and you should see the following: 
        Cannot use udtsend command to send message to yourself.
  • Type "udtsend :12000 how are you?" in the 3rd window and you should see the following: 
        :12000 is not reachable
  • Type "udtsend :12012 how are you?" in the 3rd window and you should see the following in the 3rd window: 
        [TIMESTAMP] i UCASTAPP :12012 9 - 12 MSGID2 :12004 :12012 1 how are you?
  • In the 4th window and you should see the following when the UCASTAPP message is received (order doesn't matter): 
        [TIMESTAMP] r UCASTAPP :12004 9 - 12 MSGID2 :12004 :12012 1 how are you?
    No receiver for UDT message 'how are you?' from :12004.
    where MSGID2 must be identical to the MSGID2 in the 3rd window.

  • In the 2nd Terminal window, type "./lab12b lab12data/lab12-12002.ini" to restart :12002.
  • Type "forwarding" in all four windows and make sure that every node has the correct forwarding table.
  • Type "udtsend :12000 bye" in the 4th window and you should see the following in the 4th window: 
        [TIMESTAMP] i UCASTAPP :12002 9 - 3 MSGID3 :12012 :12000 1 bye
    where MSGID3 is an actual value.

  • In the 2nd window and you should see the following when the UCASTAPP message is forwarded: 
        [TIMESTAMP] r UCASTAPP :12012 9 - 3 MSGID3 :12012 :12000 1 bye
    [TIMESTAMP] f UCASTAPP :12000 8 - 3 MSGID3 :12012 :12000 1 bye
    where MSGID3 must be identical to the MSGID3 in the 4th window.

  • In the 1st window and you should see the following when the UCASTAPP message is received (order doesn't matter): 
        [TIMESTAMP] r UCASTAPP :12002 8 - 3 MSGID3 :12012 :12000 1 bye
    No receiver for UDT message 'bye' from :12012.
    where MSGID3 must be identical to the MSGID3 in the 4th window.

  • Type "quit" in all 4 windows and make sure that they all terminated gracefully.
  • In the 4th Terminal window, type the follow to display all the log files (to see that SAYHELLO and LSUPDATE messages are properly logged): 
        more lab12data/*.log
  • Type "exit" in all 4 windows to close the transcripts.
To save typing all some of the commands above, a tmux script, "tmux-lab12b.txt" is provided in the "lab12data" directory created above and you can run it by typing: 
    lab12data/tmux-lab12b.txt
Plesae note that it's provided for your convenience (i.e., to save typing) and it may not be exactly the same as the above sequence. Please see PA2 FAQ regarding how to use tmux in general.

Templates
The above specificiation has enough details, so pseudo-code is not provided.

Grading
Below is the grading breakdown:
  • (1 pt) submitted a valid lab12.tar.gz file with all the required files using the submission procedure below
  • (1 pt) content in "lab12a-12000.script", "lab12a-12002.script", "lab12a-12004.script", and "lab12a-12012.script" are correct
  • (1 pt) content in "lab12b-12000.script", "lab12b-12002.script", "lab12b-12004.script", and "lab12b-12012.script" are correct
  • (1 pt) "Makefile" works for "make lab12a" and "make lab12b"
  • (1 pt) source code of your node looks right
Minimum deduction is 0.5 pt for anything that's incorrect. Please note that for the "Makefile" item, you can only get credit for it if your "source code" is relevant to this lab; therefore, you can only get as many points as the "source code" item in the best case.

Please keep in mind that even though lab grading is "light", it doesn't mean that you can just put anything into your submission! It's still your responsibility to make sure that the files in your submission contains information that's relevant to the tests you were supposed to run. Use the "more" command to view your script/log files to make sure that they contain the right information. If a file has the wrong stuff in it, you should delete it and create the file again and verify. If most of the stuff in your script/log files are wrong and you did not notice it, we will most likely have to take points off.

Submission
To submit your work, you must first tar all the files you want to submit into a tarball and gzip it to create a gzipped tarfile named "lab12.tar.gz". Then you upload "lab12.tar.gz" to our Bistro submission server.

Change into the "lab12" directory you have created above and enter the following command to create your submission file "lab12.tar.gz" (if you don't have any ".h" files, don't include "*.h*" at the end): 

    tar cvzf lab12.tar.gz lab12*.script Makefile *.c* *.h*
    ls -l lab12.tar.gz
The last command shows you how big the created "lab12.tar.gz" file is. If "lab12.tar.gz" is larger than 1MB in size, the submission server will not accept it.

If you use an IDE, the IDE may put your source code in subdirectories. In that case, you need to modify the commands above so that you include ALL the necessary source files and subdirectories (and don't include any binary files) ane make sure that your code can be compiled without the IDE since the grader is not allowed to use an IDE to compile your code.

You should read the output of the above commands carefully to make sure that "lab12.tar.gz" is created properly. If you don't understand the output of the above commands, you need to learn how to read it! It's your responsibility to ensure that "lab12.tar.gz" is created properly.

To check the content of "lab12.tar.gz", you can use the following command: 

    tar tvf lab12.tar.gz
Please read the output of the above command carefully to see what files were included in "lab12.tar.gz" and what are their file sizes and make sure that they make sense.

Please enter your USC e-mail address and your submission PIN below. Then click on the Browse button and locate and select your submission file (i.e., "lab12.tar.gz"). Then click on the Upload button to submit your "lab12.tar.gz". (Be careful what you click! Do NOT submit the wrong file!) If you see an error message, please read the dialogbox carefully and fix what needs to be fixed and repeat the procedure. If you don't know your submission PIN, please visit this web site to have your PIN e-mailed to your USC e-mail address.

When this web page was last loaded, the time at the submission server at merlot.usc.edu was 27Nov2025-18:59:22. Reload this web page to see the current time on merlot.usc.edu.

USC E-mail:    @usc.edu
Submission PIN:  
Event ID (read-only):  
Submission File Full Path:  
   
 
If the command is executed successfully and if everything checks out, a ticket will be issued to you to let you know "what" and "when" your submission made it to the Bistro server. The next web page you see would display such a ticket and the ticket should look like the sample shown in the submission web page (of course, the actual text would be different, but the format should be similar). Make sure you follow the Verify Your Ticket instructions to verify the SHA1 hash of your submission to make sure what you did not accidentally submit the wrong file. Also, an e-mail (showing the ticket) will be sent to your USC e-mail address. Please read the ticket carefully to know exactly "what" and "when" your submission made it to the Bistro server. If there are problems, please contact the instructor.

It is extreme important that you also verify your submission after you have submitted "lab12.tar.gz" electronically to make sure that every you have submitted is everything you wanted us to grade. If you don't verify your submission and you ended up submit the wrong files, please understand that due to our fairness policy, there's absolutely nothing we can do.

Finally, please be familiar with the Electronic Submission Guidelines and information on the bsubmit web page.