Server reference implementations for both a software-based TCP/IP stack and a iChip based socket interface were developed as Windows console applications.  Both of the implementations were tested against client programs written in C# .NET (Visual Studio 2003, .NET Framework 1.1)  and Java (Eclipse, J2SE 1.4.2, Sun’s Java Web Services Developer Pack 1.3).  In both cases, access to the web service was automatically generated from the WSDL and the client program simply called stubs.  The software stack version of the server required less than 1000 lines of C++.  The chip based version required less than 1400 lines of C++ [NOTE: since this implementation requires no software based TCP/IP stack the overall size is significantly smaller].  This would be in the range of 6 to 9 Kbytes of ROM in a M68HC12 micro-controller.  The addition of each new message to the web service would require on the average only fifteen lines of code, so even a very complex message set would not require significantly more code.  Though this is not tiny, it can easily fit in a wide variety of devices implemented on modest platforms.

Performance

The performance of the Internet chip version was substantially less than that of the socket interface version.  Part of this is undoubtedly caused by the fact that the chip set used only supported a dial-up connection.  But the main contributor is the serial interface used between the Internet chip and the main processor and the specific procedures that needed to be completed to retrieve data received by the Internet chip.  In general the Internet chip should be restricted to five or less simultaneous connections (it supports up to ten).  In many, if not most, cases neither the performance or number of simultaneous connections is not likely to be an issue.

There is of course a significant price for using the web service approach -- the amount of data moved is significantly larger.  Where a proprietary protocol running on top of TCP/IP could use less than ten bytes to perform a GetShort, the web service used 900 bytes.  The reference implementations include the ability to limit the number of simultaneous connections to keep the load this represents from overwhelming the device.

Security

Security is probably the biggest problem in this connected world.  Currently there is no standardized method for web service security, though one is in the works.  The current draft does not appear to be suitable for smart devices, at least ones implemented on a modest platform.  The scheme used in the reference implementations provides good but not perfect security.  If sessions are maintained for long periods, especially if the device’s IP address is static and exposed to the outside world, there is some chance of a session being hijacked.  The reference implementations address this partially by closing a connection that has been inactive for some time.  The scheme provides no protection against monitoring or denial of service type attacks.  The scheme does impose some potential administrative problems on the client side since each connection requires the key generated in the prior connection for the specific user.