Hardwired TCP/IP Chapter 30: W55MH32 HTTP

Hardwired TCP/IP Chapter 30: W55MH32 HTTP_Server & NetBIOS Example

COMPONENTS

PROJECT DESCRIPTION

Hardwired TCP/IP Chapter 30: W55MH32 HTTP_Server & NetBIOS Example

In this article, we will provide a detailed explanation on how to implement the HTTP_Server and NetBIOS functions on the W55MH32 chip. Through practical examples, we will also explain to you how to access the web content of the HTTP server via NetBIOS.

Other network protocols used in this routine, such as DHCP, please refer to the relevant sections. Regarding the initialization process of W55MH32, please also refer to the relevant sections. We will not elaborate on it here.

1 HTTP Server & NetBIOS Introduction

By implementing HTTP_Server through NetBIOS, the traditional HTTP service is combined with the NetBIOS name resolution function, enabling HTTP requests and responses based on the NetBIOS names within the local area network. Usually, NetBIOS is used for device discovery and name resolution in the local area network. Therefore, the HTTP server can be accessed through the NetBIOS name instead of the IP address, simplifying the configuration and communication of devices in the network environment.

2 HTTP_Server & NetBIOS Features

Name Resolution: By utilizing the NetBIOS name resolution function, the client can access the HTTP server using the computer name instead of the IP address, simplifying network configuration, especially in environments without a DNS server.
Local Area Network Optimization: Suitable for use within the local area network, it can provide HTTP services without an internet connection, facilitating communication and resource sharing between devices.
No Complex Configuration Required: Through NetBIOS, automatic device discovery and name resolution are provided, reducing reliance on IP address configuration, making device interconnection more convenient.
Compatibility: Applicable to older systems or outdated hardware devices, especially in Windows systems, NetBIOS and HTTP servers can be smoothly integrated.
Improved Network Efficiency: Through the lightweight communication mechanism provided by NetBIOS, HTTP services can offer fast and stable data transmission in the local area network environment.

3 Basic Workflow of HTTP_Server & NetBIOS

1. Initialization: The HTTP server starts up and broadcasts its name within the local network using the NetBIOS over TCP/IP (NBT) protocol.

2. Name Resolution: The client obtains the IP address of the server through the NetBIOS Name Resolution Service (NBNS).

3. Client Request: The client sends an HTTP request to the HTTP server via a TCP connection.

4. Request Processing: The server processes the request, generates the corresponding HTTP response, and prepares to return it.

5. Response Return: The server sends the response data (such as a web page or file) back to the client via the TCP connection.

6. Session Closure: After the request is completed, the server and the client close the connection or keep it open to wait for the next request.

7. End and Cleanup: The server releases resources and prepares to handle the next request.

The HTTP request-response model typically consists of the following steps.

Establish connection: A connection is established between the client and the server based on the TCP/IP protocol.
Send request: The client sends a request to the server, which includes the URL of the resource to be accessed, the request method (GET, POST, PUT, DELETE, etc.), request headers (such as Accept, User-Agent), and an optional request body (for POST or PUT requests).
Process request: After receiving the request, the server finds the corresponding resource based on the information in the request and performs the corresponding processing operation. This may involve retrieving data from a database, generating dynamic content, or simply returning a static file.
Send response: The server encapsulates the processed result in a response and sends it back to the client. The response includes a status code (used to indicate the success or failure of the request), response headers (such as Content-Type, Content-Length), and an optional response body (such as an HTML page, image data).
Close connection: After completing the request-response cycle, the connection between the client and the server will be closed, unless a persistent connection (such as keep-alive in HTTP/1.1) is used.

4 HTTP Request Methods

In the HTTP protocol, GET and POST are two commonly used request methods, used by the client to send data to the server and obtain resources.

GET Method

The GET method is typically used to retrieve resources from the server. It has the following characteristics:

Parameter passing: Request parameters are passed through the query string in the URL, in the form of ?key1=value1&key2=value2.
Data size limit: Since the parameters are appended to the URL, their length may be limited by the URL length (depending on the settings of the browser and server).
Security: The data is displayed in plain text in the URL, and is not suitable for transmitting sensitive information.

Request format:

GET <Request-URI> HTTP/<Version>
<Headers>
<Blank Line>

Request-URI: Represents the path of the target resource, which may include parameters.
Version: HTTP protocol version.
Headers: Contains metadata, such as client attributes, supported formats, etc.
Blank Line: Empty line.

POST method

The POST method is typically used to submit data to the server. It has the following characteristics:

Parameter passing: Data is placed in the request body instead of in the URL.
Data size limit: There is no obvious limit on the volume of POST requests, and a large amount of data can be transmitted.
Security: Data is transmitted in the request body, which is relatively more secure.

Request format:

POST <Request-URI> HTTP/<Version>
<Headers>
<Blank Line>
<Body>

Field Explanation:

Request-URI: The path of the target resource, usually the endpoint of the API.
Headers: Metadata, such as content type and length.
Blank Line: A blank line, used to separate headers from the body.
Body: The main body of the data, containing the length of the data sent by the client to the server.

5 HTTP Protocol Response Content

The HTTP protocol response content consists of three parts: the status line, the response header, and the response body.

Status Line

The HTTP status line includes the HTTP protocol version, the status code, and the status description.

The status code is composed of three decimal numbers, and the first decimal number defines the type of the status code.

The status codes are divided into five categories:

1xx (Informational Status Code): Indicates that the received request is being processed.
2xx (Successful Status Code): Indicates that the request has been processed successfully.
3xx (Redirection Status Code): Requires subsequent actions to complete this request.
4xx (Client Error Status Code): Indicates that the request contains a syntax error or cannot be completed.
5xx (Server Error Status Code): The server encountered an error while processing the request.

Example:

HTTP/1.1 200 OK

Response headers

The response headers will contain information such as content type, length, and encoding.

Common response header fields include:

Content-Type: The MIME type of the response content, such as text/html, application/json.
Content-Length: The byte length of the response content.
Server: Information about the server.
Set-Cookie: Sets the Cookie for the client.

Example:

Content-Type: text/html; charset=UTF-8
Content-Length: 3495
Server: Apache/2.4.41 (Ubuntu)

Response body

The response body contains the actual data content, and its specific form depends on the type of response and the content of the request. For example: HTML page content, JSON data, binary data of a file, etc.

If the status code of the response is 204 No Content or 304 Not Modified, there is usually no body.

Note: An empty line is added between the response body and the response header to separate the content.

6 Basic Components of a Web Page

HTML (HyperText Markup Language)

Function: Defines the structure and content of the web page.
Content:
- Structural Label：如 <html>、<head>、<body>。
- Content Tag：如 <h1>、<p>、<img>、<a>。
- Form label：如 <form>、<input>、<button>。

CSS (Cascading Style Sheets)

Function: Control the style and layout of the web page.
Content:
Font settings: such as font-family, font-size.
Color settings: such as color, background-color.
Layout design: such as margin, padding, display, flex.
Responsive design: such as media queries (@media).

JavaScript（Scripting language）

Function: Enhance the interactivity and dynamic features of the web page.
Application:
Form validation.
Animation effects.
Interacting with the server (such as through AJAX requests).
Handling user events (such as clicks, mouseovers).

Meta Information

Function: Provides metadata for the page, which is usually included within the <head> section.
Content:
Webpage Title: <title>
Character Set: <meta charset="UTF-8">
SEO Information: Such as <meta name="description" content="Description">
Device Adaptation: Such as <meta name="viewport" content="width=device-width, initial-scale=1.0">.

Example:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Simple Page</title>
    <style>
        body { font-family: Arial, sans-serif; text-align: center; padding: 20px; }
        button { padding: 10px 20px; cursor: pointer; }
    </style>
</head>
<body>
    <h1>Hello, Web!</h1>
    <p>Click the button for a surprise.</p>
    <button onclick="alert('You clicked the button!')">Click Me</button>
</body>
</html>

7 Web Page Interaction

The way a web page makes HTTP requests:

HTTP Request Page

Description: The client sends a request to the server via the HTTP protocol, and the server processes it and then returns a response.
Feature:
The most basic interaction method.
It includes common HTTP methods such as GET, POST, PUT, DELETE, etc.
Example:
- GET Request: The browser accesses the webpage and retrieves static resources (such as HTML, CSS, JavaScript, etc.).
- POST Request: Data from the form is submitted.

Form submission

Description: Submit data to the server via an HTML form.
Feature:
- The form data will be encoded and sent along with the request.
- The GET or POST method can be used.

Example:

<form action="/submit" method="post">
    <input type="text" name="username" placeholder="Enter your name">
    <button type="submit">Submit</button>
</form>

AJAX（Asynchronous JavaScript and XML）

Description: Use JavaScript to communicate with the server in the background and update certain page content without refreshing the entire page.
Feature:
Improve user experience and reduce page loading time.
In modern development, JSON is often used instead of XML.

Example:

fetch('/api/data', {
   method: 'GET'
})
.then(response => response.json())
.then(data => console.log(data));

Web server response processing

Direct response

Definition: The server directly processes the request, returns static resources or simple dynamic content, and does not call external scripts or programs.
eatures
- Efficiency: Directly processes the request without the need for additional calls to external programs, suitable for static content.
Applicable scenarios:
- Distribution of static resources (HTML, CSS, JavaScript, images, etc.).
- Generation of lightweight dynamic content.

Work process

The client sends an HTTP request.
The server parses the request URL and locates the corresponding resource (such as the file path).
It directly reads the content of the resource and returns it to the client, along with the appropriate HTTP response headers.
CGI Response

Definition: The server invokes external programs or scripts through CGI (Common Gateway Interface) to process client requests and generate dynamic response content.
Characteristics
Flexibility: It can dynamically generate content and support complex logic.
Applicable Scenarios:
Dynamic content generation (such as user login, data query).
Complex logic processing with database interaction or other background services. Work process

Work process

The client sends an HTTP request.
The server parses the request and passes the request data (such as URL parameters or form data) to the CGI program.
The CGI program processes the request, generates the response content and returns it to the server.
The server packages the content generated by the CGI program as an HTTP response and sends it to the client.

8 HTTP_Server & NetBIOS Application Scenarios

Next, let's take a look at what operations and applications can be accomplished using HTTP_Server & NetBIOS on W55MH32?

1. Simplify device interconnection: Through NetBIOS name resolution, embedded devices can discover and access HTTP services within the local area network without relying on DNS, simplifying network configuration.

2. Automated configuration and management: NetBIOS enables devices to automatically discover and configure through names, improving the efficiency of device deployment and maintenance, especially suitable for large-scale embedded device deployments.

3. Network environment without DNS: Applicable to small local area networks or development environments without DNS, reducing the complexity of IP address management and providing a convenient device communication method.

4. Debugging and maintenance tools: The combination of NetBIOS and HTTP Server enables developers to quickly debug embedded devices, monitor system performance and perform fault troubleshooting.

5. Embedded Web services: Provide control interfaces or status monitoring based on HTTP, facilitating remote management and debugging, suitable for configuration and management of embedded devices.

9. Implementation Process

Next, we implement the HTTP_Server & NetBIOS functions on the W55MH32.

Note: The test instance requires that the PC and W55MH32 be on the same network segment.

In the main loop, the program processes HTTP and NetBIOS-related tasks in parallel. There are the following steps:

1while (1){
httpServer_run(SOCKET_ID);
do_netbios(SOCKET_ID);
5.}

Step 1: HTTP Server Processing

The httpServer_run() function is responsible for the HTTP server functionality. It listens for socket status, receives requests, processes and responds to them. For example, it returns the corresponding web page content for different GET requests, and updates the configuration and sets the restart flag when handling POST requests.

The httpServer_run() function is as follows:

  1. void httpServer_run(uint8_t seqnum)
  2. {
  3.     uint8_t  s; // socket number
  4.     uint16_t len;
  5.     uint32_t gettime = 0;
  6.  
  7. #ifdef _HTTPSERVER_DEBUG_
  8.     uint8_t destip[4] = {
  9.         0,
 10.     };
 11.     uint16_t destport = 0;
 12. #endif
 13.  
 14.     http_request        = (st_http_request *)pHTTP_RX; // Structure of HTTP Request
 15.     parsed_http_request = (st_http_request *)pHTTP_TX;
 16.  
 17.     // Get the H/W socket number
 18.     s = getHTTPSocketNum(seqnum);
 19.  
 20.     /* HTTP Service Start */
 21.     switch (getSn_SR(s))
 22.     {
 23.     case SOCK_ESTABLISHED:
 24.         // Interrupt clear
 25.         if (getSn_IR(s) & Sn_IR_CON)
 26.         {
 27.             setSn_IR(s, Sn_IR_CON);
 28.         }
 29.  
 30.         // HTTP Process states
 31.         switch (HTTPSock_Status[seqnum].sock_status)
 32.         {
 33.         case STATE_HTTP_IDLE:
 34.             if ((len = getSn_RX_RSR(s)) > 0)
 35.             {
 36.                 if (len > DATA_BUF_SIZE) len = DATA_BUF_SIZE;
 37.                 len                                = recv(s, (uint8_t *)http_request, len);
 38.                 *(((uint8_t *)http_request) + len) = '\0';
 39.  
 40.                 parse_http_request(parsed_http_request, (uint8_t *)http_request);
 41. #ifdef _HTTPSERVER_DEBUG_
 42.                 getSn_DIPR(s, destip);
 43.                 destport = getSn_DPORT(s);
 44.                 printf("\r\n");
 45.                 printf("> HTTPSocket[%d] : HTTP Request received ", s);
 46.                 printf("from %d.%d.%d.%d : %d\r\n", destip[0], destip[1], destip[2], destip[3], destport);
 47. #endif
 48. #ifdef _HTTPSERVER_DEBUG_
 49.                 printf("> HTTPSocket[%d] : [State] STATE_HTTP_REQ_DONE\r\n", s);
 50. #endif
 51.                 // HTTP 'response' handler; includes send_http_response_header / body function
 52.                 http_process_handler(s, parsed_http_request);
 53.  
 54.                 gettime = get_httpServer_timecount();
 55.                 // Check the TX socket buffer for End of HTTP response sends
 56.                 while (getSn_TX_FSR(s) != (getSn_TxMAX(s)))
 57.                 {
 58.                     if ((get_httpServer_timecount() - gettime) > 3)
 59.                     {
 60. #ifdef _HTTPSERVER_DEBUG_
 61.                         printf("> HTTPSocket[%d] : [State] STATE_HTTP_REQ_DONE: TX Buffer clear timeout\r\n", s);
 62. #endif
 63.                         break;
 64.                     }
 65.                 }
 66.  
 67.                 if (HTTPSock_Status[seqnum].file_len > 0)
 68.                     HTTPSock_Status[seqnum].sock_status = STATE_HTTP_RES_INPROC;
 69.                 else
 70.                     HTTPSock_Status[seqnum].sock_status = STATE_HTTP_RES_DONE; // Send the 'HTTP response' end
 71.             }
 72.             break;
 73.  
 74.         case STATE_HTTP_RES_INPROC:
 75.             /* Repeat: Send the remain parts of HTTP responses */
 76. #ifdef _HTTPSERVER_DEBUG_
 77.             printf("> HTTPSocket[%d] : [State] STATE_HTTP_RES_INPROC\r\n", s);
 78. #endif
 79.             // Repeatedly send remaining data to client
 80.             send_http_response_body(s, 0, http_response, 0, 0);
 81.  
 82.             if (HTTPSock_Status[seqnum].file_len == 0) HTTPSock_Status[seqnum].sock_status = STATE_HTTP_RES_DONE;
 83.             break;
 84.  
 85.         case STATE_HTTP_RES_DONE:
 86. #ifdef _HTTPSERVER_DEBUG_
 87.             printf("> HTTPSocket[%d] : [State] STATE_HTTP_RES_DONE\r\n", s);
 88. #endif
 89.             // Socket file info structure re-initialize
 90.             HTTPSock_Status[seqnum].file_len    = 0;
 91.             HTTPSock_Status[seqnum].file_offset = 0;
 92.             HTTPSock_Status[seqnum].file_start  = 0;
 93.             HTTPSock_Status[seqnum].sock_status = STATE_HTTP_IDLE;
 94.  
 95. //#ifdef _USE_SDCARD_
 96. //                                                                                                         f_close(&fs);
 97. //#endif
 98. #ifdef _USE_WATCHDOG_
 99.             HTTPServer_WDT_Reset();
100. #endif
101.             http_disconnect(s);
102.             break;
103.  
104.         default:
105.             break;
106.         }
107.         break;
108.  
109.     case SOCK_CLOSE_WAIT:
110. #ifdef _HTTPSERVER_DEBUG_
111.         printf("> HTTPSocket[%d] : ClOSE_WAIT\r\n", s); // if a peer requests to close the current connection
112. #endif
113.         disconnect(s);
114.         break;
115.  
116.     case SOCK_CLOSED:
117. #ifdef _HTTPSERVER_DEBUG_
118.         printf("> HTTPSocket[%d] : CLOSED\r\n", s);
119. #endif
120.         if (socket(s, Sn_MR_TCP, HTTP_SERVER_PORT, 0x00) == s) /* Reinitialize the socket */
121.         {
122. #ifdef _HTTPSERVER_DEBUG_
123.             printf("> HTTPSocket[%d] : OPEN\r\n", s);
124. #endif
125.         }
126.         break;
127.  
128.     case SOCK_INIT:
129.         listen(s);
130.         break;
131.  
132.     case SOCK_LISTEN:
133.         break;
134.  
135.     default:
136.         break;
137.  
138.     } // end of switch
139.  
140. #ifdef _USE_WATCHDOG_
141.     HTTPServer_WDT_Reset();
142. #endif
143. }

This function is used to handle the operation logic of the HTTP server. The function accepts a parameter seqnum, which represents the sequence number of the currently processed socket. After entering this function, the program will execute a state machine, performing different operations based on the state of the Socket.

When the Socket is in the SOCK_CLOSED state (closed state), the program will open and reinitialize the socket;

When it is in the SOCK_ESTABLISHED state (connected state), it will first clear the interrupt flag, then perform different processing based on the state of the socket. In the idle state, it will receive and parse the data, handle the HTTP request, and send the response, and update the state according to the file length; during the response processing, the state is when sending the remaining response data, and when the file transfer is completed, it switches to the response completion state; after the response is completed, it resets the file information and closes the socket, returning to the idle state;

SOCK_CLOSE_WAIT is the closed waiting state. At this time, the disconnect() function is called to close the socket;

SOCK_INIT indicates the initialization state. The listen() function is called to listen for connections;

SOCK_LISTEN is the listening state. No operations are performed.

Step 2: NetBIOS Service Processing

The do_netbios() function implements NetBIOS name resolution. When in the SOCK_UDP state and receiving a data packet, if it is a query for the local NetBIOS name, it constructs and sends a response packet. In the SOCK_CLOSED state, it reopens the socket. Through this cyclic mechanism, the program continuously provides HTTP services and NetBIOS name resolution services.

The do_netbios() function is as follows:

 1. void do_netbios(uint8_t sn)
 2. {
 3.     unsigned char state;
 4.     unsigned int  len;
 5.     state = getSn_SR(sn);
 6.     switch (state)
 7.     {
 8.     case SOCK_UDP:
 9.         if ((len = getSn_RX_RSR(sn)) > 0)
10.         {
11.             unsigned char     rem_ip_addr[4];
12.             uint16_t         rem_udp_port;
13.             char             netbios_name[NETBIOS_NAME_LEN + 1];
14.             NETBIOS_HDR      *netbios_hdr;
15.             NETBIOS_NAME_HDR *netbios_name_hdr;
16.             len = recvfrom(sn, (unsigned char *)&netbios_rx_buf, len, rem_ip_addr, &rem_udp_port);
17.             printf("rem_ip_addr=%d.%d.%d.%d:%d\r\n", rem_ip_addr[0], rem_ip_addr[1], rem_ip_addr[2], rem_ip_addr[3], rem_udp_port);
18.             netbios_hdr      = (NETBIOS_HDR *)netbios_rx_buf;
19.             netbios_name_hdr = (NETBIOS_NAME_HDR *)(netbios_hdr + 1);
20.             // If the packet is a NetBIOS query packet
21.             if (((netbios_hdr->flags & ntohs(NETB_HFLAG_OPCODE)) == ntohs(NETB_HFLAG_OPCODE_NAME_QUERY)) && ((netbios_hdr->flags & ntohs(NETB_HFLAG_RESPONSE)) == 0) && (netbios_hdr->questions == ntohs(1)))
22.             {
23.                 printf("netbios name query question\r\n");
24.                 // Decode the NetBIOS package
25.                 netbios_name_decoding((char *)(netbios_name_hdr->encname), netbios_name, sizeof(netbios_name));
26.                 printf("name is %s\r\n", netbios_name);
27.                 // If the query is made against the native Netbios
28.                 if (strcmp(netbios_name, NETBIOS_W55MH32_NAME) == 0)
29.                 {
30.                     uint8_t       ip_addr[4];
31.                     NETBIOS_RESP *resp = (NETBIOS_RESP *)netbios_tx_buf;
32.                     // Handle the header of the NetBIOS response packet
33.                     resp->resp_hdr.trans_id      = netbios_hdr->trans_id;
34.                     resp->resp_hdr.flags         = htons(NETB_HFLAG_RESPONSE | NETB_HFLAG_OPCODE_NAME_QUERY | NETB_HFLAG_AUTHORATIVE | NETB_HFLAG_RECURS_DESIRED);
35.                     resp->resp_hdr.questions     = 0;
36.                     resp->resp_hdr.answerRRs     = htons(1);
37.                     resp->resp_hdr.authorityRRs  = 0;
38.                     resp->resp_hdr.additionalRRs = 0;
39.                     // Process the header data of the NetBIOS response packet
40.                     memcpy(resp->resp_name.encname, netbios_name_hdr->encname, sizeof(netbios_name_hdr->encname));
41.                     resp->resp_name.nametype = netbios_name_hdr->nametype;
42.                     resp->resp_name.type     = netbios_name_hdr->type;
43.                     resp->resp_name.cls      = netbios_name_hdr->cls;
44.                     resp->resp_name.ttl      = htonl(NETBIOS_NAME_TTL);
45.                     resp->resp_name.datalen  = htons(sizeof(resp->resp_name.flags) + sizeof(resp->resp_name.addr));
46.                     resp->resp_name.flags    = htons(NETB_NFLAG_NODETYPE_BNODE);
47.                     getSIPR(ip_addr);
48.                     memcpy(resp->resp_name.addr, ip_addr, 4);
49.                     // Send a response packet
50.                     sendto(sn, (unsigned char *)resp, sizeof(NETBIOS_RESP), rem_ip_addr, rem_udp_port);
51.                     printf("send response\r\n");
52.                 }
53.             }
54.         }
55.         break;
56.  
57.     case SOCK_CLOSED:
58.         close(sn);
59.         socket(sn, Sn_MR_UDP, NETBIOS_PORT, 0);
60.         break;
61.  
62.     default:
63.         break;
64.     }
65. }

The do_netbios() function mainly performs NetBIOS-related operations. The program first executes a state machine, which performs different operations based on the socket state: when in the closed state (SOCK_CLOSED), it closes and re-creates the socket to listen on the NetBIOS port; in the UDP state (SOCK_UDP), it receives data and parses the NetBIOS query packet, and sends a response packet when matching the local name; in other states, no operation is performed.

10. Running results

After the burning routine is executed, the PHY link is first detected, then the network address is obtained through DHCP and the network address information is printed. The prompt name is printed through NetBIOS name resolution. Next, we open the browser and enter W55MH32/ to access the web page information.

11 Summary

This article explains how to implement the HTTP_Server and NetBIOS functions on the W55MH32 chip, and accesses the web content of the HTTP server through NetBIOS. Through practical examples, it demonstrates the process of concurrently handling HTTP and NetBIOS-related tasks in the main loop. Thank you for watching!

WIZnet is a non-fabrication semiconductor company founded in 1998. Its products include the Internet processor iMCU™, which adopts TOE (TCP/IP Offloading Engine) technology and is based on a unique patented fully hardwired TCP/IP. iMCU™ is designed for embedded Internet devices in various applications.

WIZnet has over 70 distributors worldwide, with offices in Hong Kong, South Korea, and the United States, providing technical support and product marketing.

The region managed by the Hong Kong office includes: Australia, India, Turkey, and Asia (excluding South Korea and Japan).

Documents

Comments Write