Limited TCP/IP implementation using minimal resources

Systems and methods for providing a highly useful partial implementation of a network protocol using limited processing and memory resources are provided. This allows network nodes embedded in simple devices such as light switches, thermostats, etc. to be reached using conventional open standard network protocols such as TCP/IP. A representative application is remotely adjusting a house thermostat by accessing a web page.

BACKGROUND OF THE INVENTION

The present invention relates to communication across a network in accordance with a protocol, and more particularly to systems and methods for employing minimal resources to provide a partial implementation of the protocol.

With the continued growth of the Internet, a great deal of attention is focused on the potential applications of broadband communication services for businesses and residences. Ubiquitous video conferencing, video on demand services that allow any movie to be watched anywhere at any time, and increasingly realistic network games are all envisioned. All of these applications involve very high-speed transmission of data between devices that incorporate very fast processors and ample memory resources.

However, there is also great potential utility in providing Internet access to appliances such as thermostats, hot water heaters, burglar alarms, light switches, etc. With the advent of inexpensive integrated circuits, these appliances often include processing capability in the form of low-cost microcontrollers. Such microcontrollers may operate at relatively low speeds and may incorporate less than 1 K of RAM and less than 64K of ROM.

It would be desirable to provide Internet access to such appliances. For example, one could, prior to coming home, set a desired house temperature and turn on an exterior light. A security company could readily monitor a large number of widely dispersed proximity sensors from a central location. There are also factory applications such as turning conveyer belts on and off. It would be especially desirable to accomplish all of these functions by accessing web pages. These requirements lead directly to the desirability of implementing Internet protocols such as TCP/IP and HTTP on the already ubiquitous microcontrollers.

A problem arises in that the full implementation of protocols such as TCP/IP and HTTP is in fact quite complex and beyond the memory and processing resources of low cost microcontrollers as are found in thermostats, burglar alarms, etc. What is needed are systems and methods for providing Internet capability to devices that do not incorporate sufficient processing power and/or memory resources.

SUMMARY OF THE INVENTION

Systems and methods for providing a highly useful partial implementation of a network protocol using limited processing and memory resources are provided by virtue of one embodiment of the present invention. This allows network nodes embedded in simple devices such as light switches, thermostats, etc., to be reached using conventional open standard network protocols such as TCP/IP. A representative application is remotely adjusting a house thermostat by accessing a web page.

A first aspect of the present invention provides a method for operating a server to handle a request from a client. The method includes: receiving a packet via a network interface from the client, determining a response to the packet based on progress within a predefined interaction, the predefined interaction following a protocol fully implemented by the client but not by the server, and transmitting the response to the client.

A second aspect of the present invention provides apparatus for operating a server to handle a request from a client. The apparatus includes: a network interface that communicates with the client via a network, a memory system that stores information representing a predefined interaction between the server and the client, the predefined interaction following a protocol fully implemented by the client but not by the server, and a processor that responds to the request based on the information representing the predefined interaction.

DESCRIPTION OF SPECIFIC EMBODIMENTS

The present invention will be described with reference to an example partial implementation of TCP/IP and HTTP that provides a simple web server capable of responding to a request for a web page. The present invention, however, may be applied to partially implement any suitable network protocol.

In one embodiment, a partial protocol implementation is provided by pre-storing a first series of input templates used to identify protocol packets that may be received and a second series of response templates used to generate a response. When a packet is received via the network, it is compared to relevant input templates and a match is found. Relevant variable portions of the received packet are extracted and a template for the response packet is selected. Appropriate information is inserted at selected points in the selected response template to form a response packet.

FIG. 1depicts one possible client-server application according to one embodiment of the present invention. Within a house102there is a thermostat104. The thermostat permits one to monitor and control the interior temperature of house102. As is known in the art, a microcontroller may be provided for controlling the operation of thermostat104. The microcontroller and associated circuitry may provide, for example, a local digital display of thermostat status, a touch screen or keypad for data entry, etc.

According to one embodiment of the present invention, the microcontroller may also implement a server106to permit remote operation of thermostat104including both reading and setting of temperature. Server106is coupled to a network108. In one embodiment, network108is the Internet. House102may be equipped with a residential access gateway (not shown) incorporating DSL, cable modem, or wireless technology to provide access to network108. Also server106may interface with this residential gateway using a home Ethernet, home wireless network, etc.

Many different nodes may access server106via network108including a representative client110. Client110is, in one example, a desktop computer at the work place of a resident of house102. Client110is equipped with full implementations of protocol such as TCP/IP and HTTP. Server106, however, operates in accordance with these protocols but only in a limited set of situations that have been anticipated in advance. In one embodiment, server106implements a simple web page for reading and adjusting temperature parameters of thermostat104.

FIG. 2depicts details of server106according to one embodiment of the present invention. A processor202performs network protocol operations as described below and also provides electronic control of thermostat104. Processor202may be a microcontroller such an eight-bit microcontroller. In one embodiment, processor202is one of the COP800 series of microcontrollers available from National Semiconductor, Inc. of Santa Clara, Calif. Processor202may, however, be implemented in any suitable way. Instructions for operating processor202may be stored in a read-only-memory (ROM)204. In one embodiment, ROM204may include less than 64K of capacity. In operation, instructions for processor202may also be temporarily stored in a program and data memory206that may be implemented as random-access-memory (RAM). Memory devices204and206are only representative examples of computer-readable storage media that may be used. Instructions for processor202may be stored on a floppy disc, CD-ROM, etc. Also, another example of a computer-readable storage medium usable for storing instructions for processor202is loading the instructions from the network.

Processor202connects to network108via a network interface208. Network interface208may be, e.g., an Ethernet network interface or any suitable network interface. A serial interface210is provided to send data to and from relevant components and/or transducers of thermostat104. Note that it is possible to combine many of the elements ofFIG. 2within a single integrated circuit to provide further miniaturization and reduced cost.

FIG. 3depicts a representative web page302operated by server106according to one embodiment of the present invention. A field304displays the current temperature. A field306allows the user to set a desired temperature for house102. Web page302, rather than being stored explicitly, is stored within ROM204in the form of a series of templates used to generate responses to requests for the web page. An insertion point identifier such as an escape sequence as known in the art may be used where appropriate within the templates to mark where the current temperature should be included when generating the web page.

FIG. 4depicts an interaction between client110and server106in accordance with one embodiment of the present invention. For example, client110requests the web page302depicted inFIG. 3. The interaction begins with a client110sending server106a TCP.SYN packet to request the opening of a TCP connection. Server106responds with a TCP.SYNACK packet to confirm the connection request and open a connection in a reverse direction. The final step of opening the TCP connection is a TCP.ACK packet from client110to server106confirming the opening of the reverse connection.

Next is an HTTP.REQ packet sent from client110to server106to request a web page such as the one shown inFIG. 3. Optionally, this may be combined with the TCP.ACK packet. Server106responds with a first portion of the web page contents in a TCP.DAT packet which client110acknowledges with a TCP.ACK packet. The exchange of TCP.DATA and TCP.ACK packets continues until the entire contents of the web page have been transmitted from server106to client110. Finally, client110sends a TCP.FIN packet to request that the TCP connection be closed. In response, server106sends a TCP.FINACK packet to confirm the close of the TCP connection.

In one embodiment, the present invention takes advantage of a recognition that server106need accommodate only a relatively few different types of interaction as depicted inFIG. 4. Furthermore, each of these interaction types includes only a limited number of packets that represent little information content unique to the particular client-server session. Many packets received and/or transmitted by server106will be identical except for a few values. Accordingly, a full implementation of the TCP/IP and HTTP protocols is unnecessary. Instead, server106matches received packets to an expected input template and responds by selecting an appropriate response template. Server106will typically not comply with the full requirements of the TCP protocol but will nonetheless be useful for simple applications such as providing a single web page and allowing for remote user modification of local parameters such as a thermostat temperature.

According to one embodiment of the present invention, only a very small amount of state needs to be preserved. TCP interaction will typically consist of N0incoming (client to server) and N1, outgoing (server to client packets). The connection state may only consist of a sequence index to locate where the client and server are in the interaction and the address information of the client.

FIG. 5is a flow chart describing the steps of the operation of server106in handling a received packet according to one embodiment of the present invention. At step502, server106awaits an incoming packet. There may be a TCP session in progress or server106may be awaiting the beginning of a new session. A step504tests for expiration of a timer prior to receipt of a new packet. If the timer expires before a new packet is received, the connection state of any active session is reset, effectively discarding the session, at step505. After step505, server106resumes waiting for a new packet at step502. Steps504and505may be skipped if no connection is active.

When a new packet is received, step506compares the received packet to an input template corresponding to the current connection state.FIG. 6depicts a series of input templates that represent a restricted set of TCP/IP packets. A template602represents a TCP/IP connection request (TCP.SYN) packet. Template602includes an IP header604and a TCP header606. IP header604includes all of the required header fields as known in the art. Many of these fields will be the same for all packets directed to server106but some fields such as, e.g., time to live (TTL) may be considered “don't care” fields for the purposes of finding and matching a template. The contents of a source address field608change depending on the IP address of client110. This field will be considered a don't-care field for purposes of a match for the initial state where server106is awaiting a new connection but will be checked for other connection states so that there is no other.

TCP header606includes the required fields as known in the art. Fields that will vary among individual packets include a source port field610identifying the source port on client110and a sequence number field612. A flag field614will have a bit set to indicate that the TCP packet requests a connection. Other fields will be considered to be “don't care” fields for the purposes of matching.

A template616is provided for the purpose of identifying a match to a TCP acknowledgement packet. The fields are similar to that of template602except that flag field614has a bit set to indicate acknowledgement rather than a connection request.

A template618includes an HTTP request, also in the form of a TCP packet. The IP header and TCP headers are essentially as in templates602and616although there is no particular expected value for flag field614. A TCP payload field620includes the HTTP message GET http:temp.myhouse.com. A match to this template indicates a request for the web page ofFIG. 3.

A template622also represents an HTTP request for the web page ofFIG. 3along with a request to change the thermostat set temperature. TCP payload field620thus holds an HTTP message GET http:temp.myhouse.com/q?temp=75. The value following the equal sign will of course vary with the desired temperature.

A template624represents a TCP request to terminate a connection. Template624is similar to templates602and616except that flag field614now indicates a request for disconnection.

It will be appreciated that the small set of templates depicted inFIG. 6provide matches to all of the packets generated by client110in the interaction ofFIG. 4. In one embodiment, the templates are stored in ROM204with the various fields that have variable values being indicated by e.g., special escape codes. There may also be escape codes to indicate the locations of the destination address and destination port. These values will typically be programmable depending on the appropriate network settings and would be added in by processor202before using the templates for matching purposes. In one embodiment, duplicate templates are stored with the IP and TCP headers compressed as known in the art.

It will be appreciated that during step506, the incoming packet need only be compared to the template(s) corresponding to the current connection state, i.e., the current position in the interaction ofFIG. 4. Step508tests whether the incoming packet is in fact a match. The matching process takes into account any expected layer2encapsulation information. If the incoming packet is not a match then execution proceeds back to step502to continue waiting for the next expected incoming packet without resetting the timer. It could also be that there is an active connection but the incoming packet represents a request from a new client. In the embodiment described here, these requests are ignored and only one active connection is permitted but it is also possible to respond to such a request by spawning a new session. Thereafter, incoming packets would be compared to the templates appropriate to the connection state of all active connections.

If at step508, it is determined that the incoming packet matches the response template selected for the current connection state, the timer is reset at step510. Then, at step512, any relevant variables are extracted from the received packet. For the initial request, this will include the source address and source port for the purpose of identifying the destination of a response packet. If the packet conforms to template622, the users input for temperature will be extracted as input to the appropriate temperature control algorithm.

At step514, a response template is selected based on the match identified in step508and the contents of any relevant variables.FIG. 7depicts various response templates used to support the interaction depicted inFIG. 4. A template702is used to construct the TCP.SYN.ACK packet sent by server106in setting up a TCP connection. An IP header704includes fixed values for various required fields (not shown) and a destination address field706for inserting the IP address of client110. A TCP header field708also includes fixed values for various required fields and a destination port field710for inserting the port number of the requesting port on client110. TCP header708also includes an acknowledgment number field712for inserting a value indicating the sequence number of the TCP connection request from client110.

There is a sequence number field714for inserting a pseudo-randomly selected initial sequence number for the connection from server106to client110. It is also possible to save computation time by always using the same number here in violation of TCP protocol requirements. A flag field716indicates that this is both an acknowledgment of the connection request to client110and a request to open a connection to client110.

A template718is used to form the first TCP.DATA packet ofFIG. 4. This packet includes the beginning of the contents of the web page ofFIG. 3. Acknowledgement field712is used to insert sequence number information obtained from the received HTTP request packet. Sequence field714is used to insert sequence number information appropriate to the progress of the TCP session. Flag field716has an acknowledgement bit set to acknowledge the receipt of the HTTP request. A payload field720of the TCP packet includes the beginning of an HTTP message. The message is prefaced by an HTTP header such as “HTTP/1.1 202 Accepted” that indicates that server106is fulfilling the client's request. This header is then followed by the web page contents as described by HTML as known in the art. The HTTP header may also include a field specifying the length of the whole HTTP message. The web page may be carried by multiple TCP packets.

A template722is used to form TCP.DATA packets carrying further HTML data representing the web page. The further web page contents are stored in a TCP payload field724in the form of a continuation of the HTTP message begun by the packet based on template718. The needed number of different templates along the lines of template722will depend on the length of TCP packets being used and the amount of data needed to represent the web page ofFIG. 3. Server106will typically employ a packet size between 100 to 300 bytes to assure maximum client compatibility, at the expense of extra template storage and some network inefficiency. An escape code sequence may be placed at the appropriate point in the HTML code representing the web page to indicate where current temperature data is to be inserted.

A template726is used to form the TCP.FINACK packet ofFIG. 4that confirms the closing of the TCP connection to client106. The packet structure is similar to that of template702. Acknowledgement field712is for inserting the sequence number of the connection close request. Sequence number field714is for inserting a sequence number range appropriate to the TCP session state. Flag field716holds an indication that the packet is a confirmation of the connection close.

The templates ofFIG. 7may be stored in ROM204. To preserve programmability of the IP address of server106, it may be useful to insert the source address and source support fields as part of the packet processing operation rather than pre-storing them in ROM204. Again, as inFIG. 6, the locations of any fields for which values should be inserted may be identified by escape sequences as known in the art.

Now that the templates ofFIG. 7have been presented, the process of selecting a response template at step508may be explained in greater detail. The response template is selected based on the current connection state. For example, if the client is requesting a connection (input packet was a TCP.SYN packet matching template602) then response template702. If the session is at a point such that the received packet was an HTTP request matching template618then a response template718corresponding to the selected web page is selected. If the connection state is such that the received packet was a TCP.FIN matching template624, then response template724is selected.

The response to a TCP.ACK packet that matches response template616will depend on where the client and server are in the interaction depicted inFIG. 4as indicated by the stored connection state information. After transmission of the TCP.SYNACK, a received TCP.ACK is assumed to represent confirmation of the opening of the TCP connection and no response is necessary. Following an HTTP.REQ an appropriate one of the stored templates722is selected depending on how much of the requested web page has already been transmitted.

At step516, server106completes forming the response packet by filling in the relevant variables. For template702, the destination address field706, and destination port field710are taken from the source address and source port field of the received TCP.SYN packet. The contents of acknowledgement field712are determined based on the contents of the sequence number field in the TCP.SYN packet. The sequence number may be pseudo-randomly generated in order to economize on processing power or a fixed number may be used to initiate each TCP connection.

For template718, the same variables discussed in reference to template702will also be inserted at the appropriate points. Furthermore, a variable corresponding to the current temperature may be inserted at an appropriate point in the HTML code found in payload field720. The acknowledgment number in field712will be determined based on the contents of the sequence number field of the HTTP request. The sequence number in field714is chosen in accordance with the TCP protocol as known in the art.

The fields of template722requiring inserted values are completed in the same manner as template716except that the sequence number is incremented further in accordance with the TCP protocol. Also, if the temperature variable is found in the portion of the HTML code included in template720, it is inserted at the appropriate location.

Template726is filled in with the destination address, destination port, and acknowledgment number information taken from the received TCP.FIN packet. The acknowledgment number in field712is determined based on the contents of the sequence number field of the TCP.FIN packet.

As formed, the response packet includes any necessary layer2encapsulation including PPP, etc. At step518, the response packet is transmitted over network108to client110. Any necessary MAC layer encapsulation is provided by network interface208. Furthermore, if a new temperature value has been received from client110, it is used to adjust the thermostat. At step520, the stored connection state information is update to identify where the client and server are now in the interaction ofFIG. 4, and to store the source address information of a newly received connection request.

It will be seen that a simple useful web server has been implemented with minimal processor and memory requirements by providing a partial implementation of certain Internet protocols. Essentially, the server plays back a pre-recorded packet stream.

It is understood that the examples and embodiments that are described herein are for illustrative purposes only and various modifications are changes in light there of will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the appended claims and their full scope of equivalents.