This project illustrates how to build a simple client-server setup on the ZSun embedded device, originally intended as a WiFi SD card reader. With custom firmware like OpenWRT, the ZSun becomes a versatile embedded platform. The provided C code demonstrates basic networking tasks and serves as a foundation for further development. The project was developed during a course in Real-Time Embedded Systems.
- clientBasic.c: Simple client to communicate with the server
- serverBasic.: Simple server code to manage client requests
- serverv2.c: Enhanced server with improved features.
The serverBasic.c code is designed with key features like threading for connections and a linked list to store messages. The threads managing connections are implemented using pthreads.
Connection Handling: In an infinite loop, the server waits for incoming connections. Once accepted, the new socket descriptor is stored in newSock for use in a thread. A new thread is created using pthread_create.
Thread Execution: The thread executes the handler function, which takes newSock as an argument. Depending on user commands (Send or Receive), it performs the appropriate actions:
- Send: Asks for username, message's recipient and content, stores this in a message structure, and uses a mutex to add the message to the linked list. It repeats until the user stops sending messages, then disconnects.
- Receive: Requests the client's username and uses a mutex to search for relevant messages in the linked list. The handler function retrieves and sends the messages to the client, then removes them from memory using
deleteNodeand disconnects.
Search Function: Scans the linked list to find all messages intended for a given user. Each message increases sizeofMessage by a specific size, resulting in the total byte size of the data to be sent to the client. This information is used to create the completeMessage array, which contains all messages concatenated into a data stream. The function also adds "No more messages" to indicate the end. If no messages are found, 0 is returned to signal this to the client.
Important aspects of the implementation include:
Linked Lists for Storage: Linked lists were used because they are well-suited for frequently added and deleted data. An array would consume significantly more memory and processing time for access and comparison, increasing energy consumption.
Accurate Messaging: Sender/receiver information is managed via the struct input, ensuring no incorrect messages are delivered since messages are deleted immediately after being sent.
Concurrent Connections: The server can handle multiple connections concurrently through the use of pthreads.
Message Size Limitation: The system limits message sizes to 768 bytes
Fair Server Usage: Fair use of the server is ensured through listen, which internally implements a priority queue to manage incoming connections.
The code aligns with the server logic and includes clear comments. Special attention is given to the Receive command:
Receive Handling: The client first receives the total message size from the server, allocates a buffer, and reads the complete data stream from the server. If the size is 0, it prints "No more messages for you."
To set up OpenWRT on the ZSun, I followed this guide. The key steps included:
Install libpthread: Loading libpthread.so.0 onto the ZSun for pthreads support.
Compile Server Code: Using gcc in the openwrt-zsun/zsun/staging_dir/toolchain-mips_mips32_gcc-4.8-linaro_uClibc-0.9.33.2/bin folder, I compiled serverBasic.c.
Transfer Executable: The server binary was transferred to the ZSun with:
scp serverBasic [email protected]:~/serverBasic
after establishing SSH access for remote control with:
ssh [email protected].
This process was repeated for all executable files to ensure proper deployment.
Starting the Server: The serverBasic executable is uploaded to the ZSun and launched with the command:
./serverBasic 2223
Connecting Clients: Three clients are started on separate terminals on the computer, each connecting to the server at 192.168.1.1 on port 2223 using:
./clientBasic 192.168.1.1 2223
At this point, the system setup is as follows:
Sending Messages: Two messages are sent from the upper-right user and one from the bottom terminal ones:
Closing Clients: All three users select "No" to close their terminals. A new client is started in the bottom-left terminal to read messages:
Attempting to Read Deleted Messages: A new client in the bottom-right terminal attempts to read the same messages, but they have already been deleted from the server:
Reading Remaining Messages: The remaining messages are read from the bottom-left terminal:
The following steps were taken to measure speed and CPU usage:
Six Clients: Using OpenMP, six clients were created to send messages continuously to the server.
Server Execution: The server ran on the ZSun using ./serverv2 2223.
Monitoring Load: The server on the ZSun counted received messages with a numbers variable. Every 1,000 messages, it executed uptime to log the load average.
CPU Load Average: The 5-minute load average was collected as an indicator of CPU usage. Any value above 1 suggests high CPU usage since the ZSun has a single processor.
Below is an illustrative screenshot of the server running on the ZSun while concurrently processing messages from six clients (run ./client 192.168.1.1 2223):
Consistent Message Processing: The processing time for 1,000 messages remained steady (about 2-3 seconds), as six threads were consistently looping. However, the CPU load varied due to the message storage operations.
Graph Analysis: Using the data collected from handling up to 30,000 messages, the following graph was generated after processing in MATLAB:
Load Trend Analysis: The graph shows a gradual increase in load average as the message count rises. The range between 15,000 and 25,000 messages is particularly interesting because the 15-minute load average remains relatively stable, indicating consistent CPU load during this period.
Efficiency Ratio: The ratio of (Number of Messages) / (CPU Load) is plotted below:
Optimal Load Range: In the range of 15,000 to 25,000 messages, there's a noticeable improvement in efficiency, meaning message processing per CPU load unit increases significantly. If the load average is considered an indicator of power consumption (due to increased CPU demand under heavy load), this range represents optimal performance with the best message-to-power ratio.
Message Transmission Time: By creating multiple instances of clientBasic and running them sequentially, the following results were obtained, showing the average message transmission time:
The average message transmission time was 0.0716 milliseconds, indicating swift and efficient communication.