Documentation:

Background:

Data communication protocols: A protocol is a set of rules and message formats that precisely define the interactions between communicating nodes in a data communications network. If (as is commonly the case) the protocols used by a communications network have a layered structure, then corresponding layer entities in communicating nodes in the network interact with each other using their own layer-specific protocols. Thus, the TCP entities in the source and destination nodes of an Internet connection interact with each other using the Transmission Control Protocol (TCP). At the same time, the IP entities in adjacent nodes along a communication path will interact with each other using the Internetworking Protocol (IP). A protocol stack is the implementation, at one node, in software and/or hardware, of the algorithms that implement a layered protocol. Low-level protocol layers usually handle more basic functions, such as addressing and transmission control between adjacent nodes in the network. Middle-level protocol layers take care of functions, such as end-to-end reliable packet transmission, that require more knowledge of the structure (e.g. byte sequencing) of the transmitted data. At the higher layers, applications may use protocols, such as the HyperText Transfer Protocol (HTTP), that must parse the structure and meaning of the exchanged streams of bytes that are transported over an underlying TCP/IP connection.

Internetworking Protocol (IP): The Internet is actually a world-wide collection of interconnected networks that are able to interact with each other successfully because, even though they may be based on different physical layer transmission technologies, they all use the same middle-layer communication protocols. At the so-called data link layer, the Internetworking Protocol specifies how nodes in the Internet will be uniquely identified by means of numerical addresses. In the Internet domain (as opposed to within a networked Unix file system domain), each full IP address consists of the 32-bit node address (called the IP address) and a 16-bit port number. The port number is an unsigned integer that is used as a local address to identify different software services within a network node. Many of the small-valued port numbers have been assigned standard meanings. For example, port number 80 identifies the software process (the so-called web server process) that handles incoming requests to serve out HTML-encoded information that is stored on the node. Port numbers above 2000 are generally not reserved for standard services, and can thus be used for new user-defined services.

IP is used to route data packets of variable length from the source node along a path of intervening nodes to the correct destination node. At the sending node, the local IP entity prepends an IP header to each incoming data packet (typically a TCP or UDP segment) that is passed down to it by the overlying protocol layer. The IP header is a data structure that contains the IP addresses of the source and destination nodes as well as other useful information. The IP header and associated data packet are together called an IP datagram. Each IP datagram travels separately through the Internet. The contents of the IP header are consulted by the IP entities in the intervening nodes as each IP datagram arrives so that it can be decided if the datagram has reached its destination node, or that it should be passed along to the next node in its route. If the IP datagram has indeed arrived at the destination node, then the header is stripped away by the local IP entity and the remaining packet (usually a TCP or UDP segment) is passed up to the next higher layer (usually the TCP or UDP entity) in the destination node's protocol stack.

Transmission Control Protocol (TCP): IP alone does not ensure that a stream of one or more IP datagrams will arrive in the correct order and without errors at the destination node. Such problems are taken care of in the Internet by a middle-level transport layer protocol called the Transmission Control Protocol. At the sender node, the local TCP entity prepends a TCP header to the front of each packet of user application data that it is given to transport. TCP then passes the resulting TCP segment down to the local IP layer. At the receiving node, the local TCP entity strips off the TCP headers from the arriving TCP segments and processes the TCP header information. By processing the TCP headers, the local TCP entity can detect missing segments, duplicate segments, and out-of-order segments. By not acknowledging segments, the TCP entity in the destination node will cause the TCP entity in the source node to time out and then retransmit those segments.

TCP/IP over SLIP: The standard combination of TCP running over IP is called TCP/IP. Higher-level protocols may exist on top of TCP, and lower-level protocols may exist underneath IP. In this laboratory exercise, the Linux host will be interfaced to the DUART in the microcomputer using a bi-directional serial RS232 link. A simple low-level protocol is required to break up IP datagrams into bytes so that the bytes can be transmitted one-by-one over the serial link. At the receiving end, the bytes are then reconstituted back into IP datagrams. Several such protocols have been developed for running IP over a serial line: we will be using perhaps the oldest and simplest such protocols, which is called the Serial Line Interface Protocol (SLIP). The simplest version of SLIP uses the following rules: When a data packet needs to be transmitted, simply start sending the bytes in the packet. After the last packet byte has been sent, send the END character (END = octal 300 = $C0). If an END character appears in the packet data, then send ESC-334 instead (ESC-334 = octal 333, 334 = $DB, $DC). If an ESC character appears in the packet data, then send ESC-335 instead (ESC-334 = octal 333, 335 = $DB, $DD). Note that SLIP provides no addressing information nor and error detection capabilities: it merely allows the data packet boundaries to be indicated (for the benefit of the TCP/IP stack in the destination node).

Sockets: TCP/IP functions can be called directly, but this requires extensive knowledge of the many features of TCP and IP. To simplify communication over the Internet using TCP/IP, a so-called Application Program Interface (API) is usually provided. For example, within a Unix system, processes participate in TCP/IP-controlled interactions by means of software abstractions provided by the API called sockets. If a software process within a Unix host (or a task within a MicroC/OS-II host) is expecting to be contacted in the future by software running on other hosts for the purposes of setting up a TCP/IP communications channel, then that local process (or task) creates and initializes a socket using procedure calls or traps to the local operating system. Once the socket has been properly initialized, the local TCP/IP stack will know to which process (or task) the incoming data packets should be delivered. The socket API allows a process to be blocked until the time that an expected data packet is received. When such a packet is received, then the local TCP/IP stack extracts the application data from the received IP datagram and loads it into the mailbox of the receiving process (task); then the TCP/IP stack calls the operating system to unblock the process (task) so that it will be scheduled to resume running on the local CPU.

Client-server communication: Communication over the Internet typically starts when one process, called a client process, requests information or some other service from a second process, called a server process, which typically (but not necessarily) exists on another node in the Internet. A common example of this would be a web browser client process on a personal computer requesting web pages from a departmental web server. Server processes know in advance that they may be contacted in the future over the Internet by client processes. To get ready for this possibility, a server process uses calls to the local operating system to create and initialize a new socket that will then be available to terminate requested connections. In Unix nodes, the operating system calls made by a server process to create and initialize a socket are named socket, bind, listen and accept. When a client process wishes to request a connection to a server, then it creates and initializes a socket on its own local node, then connects to the client and sends data packets to it. In Unix nodes, the operating system calls made by a client process are named socket and connect. Once a connection has been established between a client and a server, the two processes can send and receive data packets using the send and receive functions.

MicroC/OS-II extended with lwIP: In the laboratory exercise you will be using the Lightweight TCP/IP (lwIP) stack within the MicroC/OS-II environment. lwIP is a compact implementation of TCP/IP that is intended for use in embedded systems with limited memory. The API to lwIP is very similar to that in Unix, as indicated in the following table:

Unix system call	lwIP function call	Purpose
socket	netconn_new	Create a socket (clients and servers)
bind	netconn_bind	Bind a socket to a port number on the local machine (servers only)
listen	netconn_listen	Listen for connections to the socket (servers only)
accept	netconn_accept	Block the process until a client connects with the server (servers only)
connect	netconn_connect	Connect to the socket of a specified server (clients only)
send	netconn_write	Send data to the remote application (clients and servers)
receive	netconn_recv	Receive data from the remote application (clients and servers)
shutdown	netconn_delete	Closes and deletes a socket (clients and servers)

The provided code includes a server task, called tcpecho, that uses the lwIP API to create and initialize a socket in the MicroC/OS-II environment. Please study it carefully. If the tcpecho task is running on the 68332 microcomputer, then client processes on the Linux host can create sockets on the PC and then initiate connections to tcpecho over port 7.

Pre-lab Work:

Produce a flowchart or snippet of pseudocode that outlines your solution to exercise 2, and exercise 3. Each flowchart or snippet of pseudocode will be worth 5 points for a total of 10 points.

Exercise #1: Verifying the Build and Connection Over SLIP

1. Before making any connections between your breadboard and the PC, you need to load the SLIP interface on the PC. From a shell prompt run
   

   sudo slipup

   You should verify that you now have an active SLIP interface by running
   

   /sbin/ifconfig

   You should see output similar to the following lines in addition to the usual interfaces in place.

   sl0       Link encap:Serial Line IP
             inet addr:10.0.0.1  P-t-P:10.0.0.2  Mask:255.255.255.0
             UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:296  Metric:1
             RX packets:1198 errors:0 dropped:0 overruns:0 frame:0
             TX packets:1523 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:10
             RX bytes:74346 (72.6 Kb)  TX bytes:103380 (100.9 Kb)
   	

2. Connect the DB9 cable to your breadboard as was done in lab 2.
3. Retrieve the lab 3 tar file and place it in your cmpe401/ directory. Untar it using
   

   tar xvf lab3.tar

4. Build the lab3.s19 file by first changing into the lab 3 directory and typing
   

   make

   Download the lab3.s19 file to the board in the normal way.
5. After typing

   go 10000

   at the CPU32Bug prompt you should see:

   	LWIP 0.7.2 Loaded
   	Loopback Interface Up 127.0.0.1
   	Nancy's Fall2007 Duart Version
   	SLIP Interface Up 10.0.0.2
   	Network Initialized
   	TCPEcho:listening on Port 7
   	

6. From your terminal shell run
   

   ping 10.0.0.2

   The NMIX Board has been assigned IP addresss 10.0.0.2 and the Linux Host has been assigned IP address 10.0.0.1. If the pings are returned the connection has been successfully created on both the Linux side and the board side.


7. Launch a telnet session over port 7 by typing
   

   telnet 10.0.0.2 7

   at the command line in your terminal shell. This will open a connection to the TCPEcho server. When you type in some text at the command line, the TCPEcho server will echo the text back to you. You will also see some status messages in the minicom window indicating that the server has received a connection request. Close the telnet connection by typing
   

   cntrl ]

   (control key and square bracket ] key) and then typing

   quit

   The TCPEcho server should return to listening mode.


8. After you have terminated your client-server application please turn off SLIP by running
   

   sudo slipdown

   If you do not terminate SLIP the next student may not be able to access the ttyS1 (minicom 2) serial port they may need for lab #2. Please be courteous and turn off SLIP before you leave your station.

Exercise #2: Creating a menu server over port 8

1. Uncomment the

   menu_init()

   call in host.c to ensure that your menu server is created.
2. Send a welcome message to the user, as well as a list of possible commands.
3. Implement four commands:
   • toggle - sends a request to turn all LEDS on if they are off and off if they are on.
   • client port number - displays the port being used by the client (Ubuntu box)
   • time - displays the current time received from the Ubuntu box on port 13
   • bye - terminates the connection
   The case of the menu as well as the menu presented is left to your discretion and will be tested based on your choices.
4. Reject all commands that do not match one of your commands and reprompt the user.
5. Test your menu server by running
   

   telnet 10.0.0.2 8

6. Solutions to the exercises in lab 3 are mutually exclusive. Demo them individually or as a group; your choice.

Exercise #3: Web-Server Coding

1. Uncomment the call to

    httpd_init()

   in the host.c file. This will create the web server thread.
2. Use the template provided in net_apps/httpd.c to create your web server.
3. Connect to your web server by entering the following URL into Firefox:
   

   http://10.0.0.2

4. The only requirement for this exercise is that your web server display an embedded graphic of any kind (gif, jpeg, mpeg, animated gif, etc). An embedded graphic is a graphic that is loaded into memory on our board. You may use any code created for this purpose with proper attribution in your report. You may also write your own code to translate a graphic into a format that can be included in your web server code. Your choice. Remember that you have limited RAM available for this. Keep the graphic small (< 10K), or be prepared to wait forever for the code to download via minicom.

1. To get full bonus marks you must allow the user to click on an interactive element like a button or a check box to turn the LEDS on or off. Each LED must be controllable individually to get the bonus marks.
2. The interactive features could be included on your main webpage, in addition to your graphic. Or you may choose to place it on a different page. This choice is also left to your discretion, and will be tested based on the choices that you make.
3. The bonus points for this section are 10 points for the demo and 20 points for the report section of the bonus. The sum of the two portions equals 20% of the total lab mark. The maximum for this lab is therefore 120%, or 6.0% of your total grade. Good Luck!