NetSilicon's Net+50 is a 32-bit, ARM-based, single-chip solution that costs $16.95. The BOM, including 2 Mbytes of flash memory and 4 Mbytes of RAM, is $53 in quantity. This cost is significantly higher than many of the 8- and 16-bit solutions that incorporate RAM and other peripherals onto the chip.
On the other hand, Internet appliances based on 32- and 64-bit processors have the power and memory capacity to run protected-memory operating systems like Linux and a Java Virtual Machine (JVM). JVM support is needed for services like Jini. TCP/IP stacks and services are standard fare. HTML support is not a problem. These processors have no trouble handling newer data formats and protocols like XML and Simple Object Access Protocol (SOAP) where support for these—which is just beginning to appear—is available.
While HTML and direct TCP/IP port communication is the mainstay for current Internet appliances, XML and SOAP will be the basis for communication for the next generation of products (see "The New Language Of Embedded Devices," p. 78). SOAP is based on XML and Hypertext Transport Protocol (HTTP). SOAP is used by the Universal Description, Discovery & Integration (UDDI) protocol.
XML, SOAP, and UDDI are needed to address cross-platform communication issues that arise with Internet appliances. A typical environment will have Internet appliances from a host of vendors and proprietary protocols, and data-exchange formats will make a complex system completely unsupportable.
Moving to new standards like UPNP, XML, and SOAP will be easier as vendors deliver the frameworks to support them. Most developers will not want to build up this support, such as XML parsers, from scratch. This is a substantial job, and developers need to concentrate on application development.
Support for these communication standards from vendors becomes increasingly important as Internet appliances more forward from the current Internet Protocol (IP) to IP version 6 (IPv6).
IP uses a 32-bit address to identify a device. This represents a huge number of addresses, but over half have been allocated. The growth of Internet appliances will hasten the use of IP addresses.
An End To The Address Problem
The 128-bit IPv6 addressing scheme promises to end the address problem and incorporate features that the current IP protocol (IPv4) lacks, such as autoconfiguration and advanced security. IPv6 supports authentication headers and encrypted security payloads.
The big problem for Internet-appliance developers is that IPv6 support is significantly different from IP, requiring at least a change in protocol stacks (see "The Evolving Internet Protocol," p. below). Such a change is a major issue with Internet appliances, even though many are capable of automatic field upgrades.
Part of the problem is that mixing IPv4 and IPv6 on the same network is difficult at best, making it imperative that the switch to IPv6 occur at the same time for all devices on a network. Likewise, it makes it difficult to add new IPv6 devices to an IPv4 network.
One approach to the problem is to isolate an IPv4 network by using a gateway. Network address translation (NAT) is used by the gateway from IPv4 to IPv6. Most gateways already support NAT and use it to hide LAN devices behind a single IPv4 address assigned to the gateway for connection to the Internet.
The change to IPv6 is coming, but it isn't imminent. It will most likely occur on the Internet backbone. Internet appliances most likely to be affected first will be smart cell phones supported by service providers that start using IPv6 and gateways like those mentioned above.
It's clear that the Internet-appliance space must address significant software issues, such as the use of IPv6 and protocols such as SOAP. Available hardware can handle these features, and the hardware will continue to get smaller, cheaper, and faster. The difficult job for developers is to create Internet appliances that won't be logically isolated because their data formats and communication protocols are unique or incomplete.
Internet appliances are attached to local-area networks (LANs) or directly to the Internet through service providers. Although many devices use and provide services, it's easy to see devices in a client-server relationship, such as an MP3 player that gets its data from an MP3 server.
NetSilicon's Net+50 is a 32-bit, ARM-based, single-chip solution that costs $16.95. The BOM, including 2 Mbytes of flash memory and 4 Mbytes of RAM, is $53 in quantity. This cost is significantly higher than many of the 8- and 16-bit solutions that incorporate RAM and other peripherals onto the chip.
On the other hand, Internet appliances based on 32- and 64-bit processors have the power and memory capacity to run protected-memory operating systems like Linux and a Java Virtual Machine (JVM). JVM support is needed for services like Jini. TCP/IP stacks and services are standard fare. HTML support is not a problem. These processors have no trouble handling newer data formats and protocols like XML and Simple Object Access Protocol (SOAP) where support for these—which is just beginning to appear—is available.
While HTML and direct TCP/IP port communication is the mainstay for current Internet appliances, XML and SOAP will be the basis for communication for the next generation of products (see "The New Language Of Embedded Devices," p. 78). SOAP is based on XML and Hypertext Transport Protocol (HTTP). SOAP is used by the Universal Description, Discovery & Integration (UDDI) protocol.
XML, SOAP, and UDDI are needed to address cross-platform communication issues that arise with Internet appliances. A typical environment will have Internet appliances from a host of vendors and proprietary protocols, and data-exchange formats will make a complex system completely unsupportable.
Moving to new standards like UPNP, XML, and SOAP will be easier as vendors deliver the frameworks to support them. Most developers will not want to build up this support, such as XML parsers, from scratch. This is a substantial job, and developers need to concentrate on application development.
Support for these communication standards from vendors becomes increasingly important as Internet appliances more forward from the current Internet Protocol (IP) to IP version 6 (IPv6).
IP uses a 32-bit address to identify a device. This represents a huge number of addresses, but over half have been allocated. The growth of Internet appliances will hasten the use of IP addresses.
An End To The Address Problem
The 128-bit IPv6 addressing scheme promises to end the address problem and incorporate features that the current IP protocol (IPv4) lacks, such as autoconfiguration and advanced security. IPv6 supports authentication headers and encrypted security payloads.
The big problem for Internet-appliance developers is that IPv6 support is significantly different from IP, requiring at least a change in protocol stacks (see "The Evolving Internet Protocol," p. below). Such a change is a major issue with Internet appliances, even though many are capable of automatic field upgrades.
Part of the problem is that mixing IPv4 and IPv6 on the same network is difficult at best, making it imperative that the switch to IPv6 occur at the same time for all devices on a network. Likewise, it makes it difficult to add new IPv6 devices to an IPv4 network.
One approach to the problem is to isolate an IPv4 network by using a gateway. Network address translation (NAT) is used by the gateway from IPv4 to IPv6. Most gateways already support NAT and use it to hide LAN devices behind a single IPv4 address assigned to the gateway for connection to the Internet.
The change to IPv6 is coming, but it isn't imminent. It will most likely occur on the Internet backbone. Internet appliances most likely to be affected first will be smart cell phones supported by service providers that start using IPv6 and gateways like those mentioned above.
It's clear that the Internet-appliance space must address significant software issues, such as the use of IPv6 and protocols such as SOAP. Available hardware can handle these features, and the hardware will continue to get smaller, cheaper, and faster. The difficult job for developers is to create Internet appliances that won't be logically isolated because their data formats and communication protocols are unique or incomplete.
Internet appliances are attached to local-area networks (LANs) or directly to the Internet through service providers. Although many devices use and provide services, it's easy to see devices in a client-server relationship, such as an MP3 player that gets its data from an MP3 server.