Internet Draft James Dougherty (jfd@cs.stanford.edu) Internet Engineering Task Force Expiration: October, 1999 April, 1999 Web Based Device Management (WBDM) File: draft-dougherty-wbdm-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract WBDM is a reference implementation for a distributed application environment which uses Java (TM) based client code and an ANSI C server implementation portable to any operating environment that supports threads (lightweight processes with a single, shared, address space), a TCP/IP stack, and BSD-style sockets. WBDM embeds a Java (TM) application program in a server-side application program that brokers requests to a Java-enabled web-browser using only the existing HTTP 1.0 GET method and user-defined messages multiplexed or tunnelled out-of-band over a persistent HTTP protocol stream. Unlike existing HTTP server programs, WBDM does not require a server side Java interpreter, operates over existing HTTP/1.0 capable networks, minimizes TCP/IP traffic over the Internet by using persistent TCP connections, and only requires a Java (TM) enabled web browser to operate as a general purpose application program. The server module for the WBDM broker is a minimal, yet complete TCP/IP based application program that does NOT require a filesystem and incurs a minimal memory resident image depending upon the size of client object code. This application server allows for name=value property pairs to exist between the client and server as object-based distributed shared memory which can be made persistent using existing FLASH or non-volatile memory based storage subsystems. Expires 10/99 [Page 1] WBDM April, 1999 The application of WBDM technology is suitable to any distributed real-time problem domain involving HTTP enabled browsers with Java (TM) technology including but not limited to: E-Commerce, distributed transactions, management, remote control, and monitoring. Using existing technology, low cost application service systems can be implemented in embedded computing hardware: Set-Top boxes, PDAs, data acquisition systems, and server appliances can all be manipulated or controlled from a web-browser and all existing websites and Internet applications can now be constructed and packaged as a single high-performance Internet application. Table of Contents 1. Introduction 2. Network Enabled Devices 3. Hypertext Transfer Protocol (HTTP) Support 4. Host Requirements 5. Embedded Application Content 6. Dynamic HTML Support 7. Embedding a Virtual HTTP Filesystem 8. Type System 9. WebMUX Protocol 10. Client/Server Interface 11. Object Entities and Type System 12. System Requirements 13. Security 14. Extensions 15. References 16. Authors Address APPENDIX A - Reference Implementation APPENDIX B - Copyright Notices 1. Introduction This document describes the implementation of an HTTP protocol server with extensions as described in [2] as a WEBMUX protocol. The application of this implementation covers the management of networked device entities or network enabled devices however, extensions are certainly applicable to other problem domains. The provided reference source code implementation provides a distributed object-system that is used to maintain operating parameters on the device to be managed. In addition, it provides a minimal implementation portable to a broad variety of operating environmentals and a starting point for other developments based on this technology. 2. Network Enabled Devices A network enabled device is a miniature computer or microcontroller-based computer system with a local or wide area network interface that runs a TCP/IP protocol stack. In the context of this document, the goal is Expires 10/99 [Page 2] WBDM April, 1999 to provide for the management of such a device through the use of an embeddable HTTP protocol server that provides embedded application content capable of executing as a general purpose application program in the client browser. To communicate with the server, a remote procedure call (RPC) [7] mechanism is employed that tunnels commands through an HTTP protocol stream originating from the host to be managed. The RPC protocol is based on a simple integer and string type system and client and server source code is provided for both the C server and Java client. Intended for embedded application progam capabilities, the implementation provides a portable, ROM'able, turnkey application with the only other requirement being a Java enabled web browser which is used as an execution environment for client application code. 3. Hypertext Transfer Protocol (HTTP) Support The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred [1]. Since the HTTP protocol is only used as a delivery mechanism for embedded application content, only the HTTP GET method is required. This simplifies the protocol extensions for object marshalling. 4. Host Requirements The success of the Internet and the acceptance of the HTTP protocol for client/server applications has created a tremendous variation in the type of HTML[9] content returned by an HTTP protocol server. The HTML content returned by most HTTP protocol servers deployed today is rich in meta-information and in many cases contains embedded application content. The simplicity of the HTTP protocol and satisfication of the TCP/IP stack requirements as in [4] allows server implementations to return dynamically generated embedded content which can later be rendered by a client to form an application program capable of performing administrative and remote control tasks. Furthermore, the server implementation can be implemented in a fashion by which a single program can perform all user-interaction and provide a virtual system interface to the client. 5. Embedded Application Content Embedded HTML application content is considered to be any program or client-executable content which requires an auxiliary program or interpreter to render in the context of the client Web browser. Examples of embedded HTML application content include Java programs and scripts, MIME-encapsulated object-bodies, dynamically generated HTML content, browser-specific tags, etc. In the context of this document, the intention of embedded application content is to perform higher-level or more general purpose computing tasks by way of a client browser interpreting or executing that content. Expires 10/99 [Page 3] WBDM April, 1999 Since it has become a de-facto standard and is now supported in a wide variety of client web-browsers, for management of a network device, the HTTP protocol server returns a Java Applet[5] which renders as an application program and commmunicate with the device using the WebMUX protocol described below. 6. Dynamic HTML Support When a client browser contacts the device by means of a web browser which supports a Java Virtual Machine, a dynamically generated HTML page with embedded content is returned (a Java applet tag) which should provide valid definitions for the following Applet parameters: a) HOST b) PORT These parameters are then used by the Applet instance to communicate with the server (in this context, the device to be managed). The naive solution to this problem consists of hard-coding valid strings for these parameters. The next problem is knowing when and how to regenerate the HTML whenever the HOST or PORT parameters change. This unnecessarily complicates the HTTP implementation and forces the system control information to be knowledgeable of a webpage returned by the server. Development would be increasing frustrating since it does not separate interface from implementation and application programs and interfaces will most certainly change. These system parameters must be determined dynamically by the server, furthermore, use of the PORT parameter should be confined to the HTTP protocol standard WKP number (80). The rationale behind this is to provide a standard means by which an Applet communicates with the server using tunnelled or out-of-band HTTP messages (e.g. those which do not consist of the standard HTTP/1.0 GET/POST messages). To reduce TCP traffic and client/server connection establishment overhead, messages are implemented as Persistent HTTP (PHTTP) messages sent via a multiplexor protocol handler that distinguishes between a known command set and standard HTTP messages. When the client browser loads the applet, it will attempt to contact the server on the specified port. Hence, a transparent and extensible means of communication is provided between the server and HTML generation engine. The HTML Java Applet tags should all support the dynamic expansion of the C [13] "printf()" style format specifiers: a) %h -The hostname or IP address of the device to be managed. b) %p -TCP/IP port number where the service resides. The end result is that embeddable client application content can now be returned from the server (independent of configuration parameters) as in the following HTML statements: Expires 10/99 [Page 4] WBDM April, 1999 Additional format specifiers may be implemented, furthermore, these specifiers could manipulate the internal object entities which are manageable by client applications. This in effect obviates the need for CGI or other HTTP POST operations since client-manipulated client will then regenerate realtime dynamic HTML content. By convention, all files which have embedded format specifiers are named with a "dhtml" file extension. 7. Embedding a Virtual HTTP Filesystem To solve the requirement of an embedded filesystem in the device to be managed, it is sufficient to hardcode a program generated ROM table which has mappings from file GET requests to character byte arrays of data. When the client requests a file, the server then only needs to look it up in the table and based on the associated MIME[10] type, parse the HTML table data to correctly render the HOST and PORT Applet parameters for the management applet client program. Static content is included in the data segment of the application program during compilation stage by an external program which processes all of the application content listed in a file by creating a translation table that maps GET requests to a byte array. The application program can then quickly service HTTP GET requests by means of indexing a static array. romfs_tab fstab[]={ {"/ConsoleGUI.class",fd_ConsoleGUI,3194}, {"/SystemControl.class",fd_SystemControl,244}, {"/WebMuxClient.class",fd_WebMuxClient,3615}, {"/WatchDog.class",fd_WatchDog,1476}, {"/index.html",fd_index,363}, {0}}; This has the added advantage that this section of code can be linked in FLASH for fast NVRAM lookup, in addition, minimization of server content is attained since all files must be known by the mapping table (e.g. in the reference implementation, the content files are located in "files.txt" which will then generate a romtable which can be linked with the program). In addition, this has the added bonus that relative URLs can be used in HTML content linked into the application code; since static content can be easily listed as a Makefile rule dependency when creating the update, all new static content is immediately made available to the server in the next build of the application. Further enhancements to this type of GET->File data mapping algorithm involve those relating to lossless compression and MIME content/type mapping as well as string manipulation within program and data segment linkage specifications on an embedded platform. Since these are typically applicable to a specific class of machine, the details of such extensions are left out of this revision. Expires 10/99 [Page 5] WBDM April, 1999 8. Type System When a request is made by a client that is not a GET request, all communication subsequent to the request takes place using three (3) atomic types: 16-bit integer, 32-bit integer, and UTF-encoded string[3]. Hence, in the definition of the the WebMUX protocol, let the following operations be defined: w(X) -read X r(X) -write X with X = 2,4,or N bytes of data, in the case of a string, "s" indicating a single string and "s*" indicating 0 or more strings. Hence, in the proposed implementation,the following fundamental types are available: a) Short integer (16 bits) b) Integer (32 bits) c) UTF encoded strings All data values are interpreted according to the following, simple, BNF; note that other variants are possible but the basic type system present sufficies for a wide variety of applications. := [0-9]+ := [0-9a-zA-Z]+ := : := := "=" := "=" Note that aggregate types are capable of being represented with this system which is extensible to many other type systems. The system manages 32-bit address and data values as well as named arrays of strings that represent the system object entities defined in the section entitled bject Entities. The properties named can be retrieved and manipulated from remote-client, hence a simple distributed object system is maintained. Whenever a request is made of a client for a file with HTTP/1.0 GET, the system will dynamically render an internal ROM memory with the HTML encoded data for the page to be rendered. This includes searching for and expanding HOST and PORT DHTML format strings. 9. WebMUX Protocol Now that the requirements for the embedded content returned by an HTTP protocol server are simplified. It is required that the Applet only be able to communicate with the server named (HOST) on the specified TCP/IP port (PORT). The rationale behind this is to support the Applet sandbox model [14] and to enforce a security policy at the HTTP service access Expires 10/99 [Page 6] WBDM April, 1999 endpoint port (80) which simplifies firewall and client requirements. If a persistent HTTP connection can be maintained This requires that a protocol must be defined to allow the HTTP protocol server to multiplex non-standard HTTP client requests onto another communications channel, thereby allowing a tunneled HTTP stream to serve as a general purpose communications channel. At a minimum, it is sufficient to have the following protocol implementation: I. REQUEST GET (as in HTTP/1.0) MUX (defined below) Both GET and MUX requests are followed by a CRLF. MUX Is always followed by a four-byte opcode which encodes the task to be perfomed by the client. All multi-byte transactions are performed in network byte order (big-endian format). The remainer of the communications which occur from client to server consists of PHTTP request/response messages defined below. II. MUX PROTOCOL All four-byte opcodes are processed based on the following protocol definitions. The MUX protocol is initiated after a tunneled HTTP MUX command. The protocol is described algorithmically below. a) SETPROP (OP=1) Client Server w(4) r(4) w(4) r(4) r(4) w(4) The client writes a four-byte (integer) property identifier followed by its associated value. It then reads a response code back from the server indicating success or failure of the operation. Non-zero return values are considered an error and indicate that the property was not stored on the server. b) GETPROP (OP=2) Client Server w(4) r(4) r(4) w(4) r(4) w(4) The client writes a four-byte (integer) property indentifier to be retrieved, and then reads two four-byte (integer) values back from the server. The first value indicates the associated value of the property identifier. The second value represents the status of the request. Non-zero status values designate failures on retrieving the indicated property. c) SETPROPARRAY (OP=3) Expires 10/99 [Page 7] WBDM April, 1999 Client Server w(s) r(s) w(4) r(4) w(s*) r(s*) r(4) w(4) The client writes a UTF encoded string [3] that designates the property name to be stored. It then writes a four-byte (integer) indicating the number of properties to be sent, followed by that many UTF encoded strings. Finally, the client reads a four-byte (integer) value from the server indicating the status of the operation. Non-zero status values are considered an error and designates failure to store the named properties. d) GETPROPARRAY (OP=4) Client Server w(s) r(s) r(4) w(4) r(s*) w(s*) The client writes a UTF encoded string [3] that designates the property name to be retrieved. It then reads a 4-byte (integer) value from the server indicating the number of UTF encoded strings it will transmit. The client then reads that many UTF encoded strings. A 0-count on returned properties is considered non-existence or error of the requested property name. e) DISCONNECT (OP=5) The client reads a four-byte (integer) value from the server. The value returned for success is 1 decimal and indicates shutdown of the PHTTP connection initialized by the client. III. Extensions Opcodes higher than 5 decimal are considered to be user defined and/or reserved for special operations. Certain operations may be desirable in the context of character and block devices and may necessitate additional complexity with client/server implementation so those operations are merely referenced and left as an exercise to the developer. It should further be noted that the stream data could easily be encrypted using RSA[15] or preferably SOCKS [16] for higher levels of performance. This is desirable when the highest levels of system security are needed to prevent unauthorized TCP stream snooping. See 13) Security for more information on security. 10. Client/Server Interfaces I. Client RPC Stub The implementation of the client and server WebMUX protocol handlers (see WebMuxClient.java / webmux.c) depend upon the following Java 1.X Platform API for the following routines: Expires 10/99 [Page 8] WBDM April, 1999 a) java.io.DataInputStream.readInt() b) java.io.DataOutputStream.writeInt() c) java.io.DataInputStream.readShort() d) java.io.DataOutputStream.writeShort() e) java.io.DataInputStream.readUTF() f) java.io.DataOutputStream.writeUTF() It has been determined that these types are required (at a minimum) to implemented general purpose distributed shared memory between client and server application modules. II. HTTP tunnelling module (webmux.c) provides analogues for the above routines in the form of the following ANSI C [13] routines: a) int read_short(int sockfd, u_short* value); b) int write_short(int sockfd, u_short value); c) int read_int(int sockfd, int* value); d) int write_int(int sockfd, int value); e) int read_utf(int sockfd, char** string); f) int write_utf(int sockfd, char* string); All higher-level protocols are defined on top of these in the HTTP stream multiplexor or RPC [7] command tunnelling hook. This virtualizes the IO interfaces between the client browser and management application (HTTP) server and simplifies the implementation of transactions. The Java client (WebMuxClient.java) is then used to communicate using the WebMux application protocol and provides a glueless interface to any Applet or Application code. This provides extensibility by supporting atomic and aggregate types and as a bonus, allows all Server side programming to be done in "C" which is used in most embedded systems today. Java client Applet code provided supports a native 1.0.2 API [5] interface so as to run with ALL Java compliant browser implementations. This is easily accomplished by using only the protocol handling mechanisms described above as opposed to more general purpose designs given in [6] which in many practical scenarios has resulted in additional performance overhead. 11. Object Entities and Type System The management of a network enabled device requires several parameters to be manipulated via the client interface. These are attribute/value pairs of strings and integers used to configure the device to be managed. Hence, only getPropArray() and setPropArray() routines are used to access the information on the device to be managed. The following represent object names required for the management of a network enabled host. Other object names can ge defined in a similar fashion and are easily implemented by extending the base implementation. Expires 10/99 [Page 9] WBDM April, 1999 a) NETWORK CONFIGURATION (NetworkControl) 0) NAME: - official DNS name of this system. 1) PORT: - TCP/IP service port. 2) IPADDR: - IP address in a.b.c.d notation. 3) NETMASK: - Network subnet mask in a.b.c.d notation. 4) MACADDR: - Ethernet or station hardware address. 5) ROUTES: - Network routes in a.b.c.d notation, default routes are suffixed with "*". 6) ADMIN: - Administrator email address. 7) DOMAIN: - Official Domain name of this system. 8) NSLIST: - List of nameservers in a.b.c.d notation. *) USER DEFINED b) SYSTEM INFORMATION (System Control) 0) UPTIME: - Date which system was booted or reset. 1) REQUESTS: - Number of IO requests. 2) ERRORS: - Number of IO errors. *) USER DEFINED - any other atomic or aggregate type. c) ACCESS CONTROL 0) HOSTSALLOW - List of IP addresses allowed access. * USER DEFINED d) EVENTS *) USER DEFINED. - usually, a string with some information. e) Objects *) USER DEFINED. - serialized object data. The intention with e) is that other types can be implemented based upon the atomic types described and implemented above. Note further that the SNMP MUX Protocol and MIB as described in [18] is easily implemented as a subset and type extension of the WebMux protocol described in 9) WebMux protocol. This is left as an exercise to the developer and could be made more powerful with the introduction of asynchronous notification and callbacks of SNMP traps as described in [19]. 12. System Requirements The HTTP protocol server that provides the aforementioned services runs in an application context having a single shared address space. This eases implementation and provides scalability in multi-processor system architectures which can perform intelligent scheduling of tasks. The only portability issues which come up in the reference implementation involve those relating to the support and interface of the following operating system primitives which must be made available. a) Lightweight Processes or Threads [11] b) BSD-style Socket Interface [12] c) BIND or BSD-style Resolver library Expires 10/99 [Page 10] WBDM April, 1999 With the above requirements satisfied, the reference implementation is portable to most any system in existence today. The system architecture for the minimal driver is available at [17] for further information. 13. Security Security is provided by means of an access control list which is automatically initialized with the IP address of the first system that contacts the entity. Further accesses are only allowed by this learned host and successive accesses by other hosts can only be performed by an allowed host adding an access control entry. The effect is that only those individuals who have been granted access to the system are allowed whereas other receive a possibly cryptic connection denial message that does not necessarily acknowledge the existence of the host. The intention is to prevent port-snoopers from detecting an HTTP service which may be susceptible to other security loopholes. Access attempts made by hosts which are not in the ACL results in an HTTP 503 "Service Unavailable" error. Each host entry is a fully qualified DNS hostname, or an IP address which is represented internally by the system as a 32-bit integer for optimal security performance. Support for username/password authentication schemes are extensible from the existing implementation by way of the SETPROP/GETPROP interface. Encryption routines can be added for even further levels of security if required although this is left as an exercise to the reader. It should further be noted that in the event the ACL is accidentally emptied, a jumper or EEPROM reset may need to be physically located on the device to reset the system to an initial state whereby it can learn a new management client. Another possibility is to implement a command-line interface providing the same capability. Other security capabilities can be provided with password/username authentication schemes, as well as key and descriptor based encryption algorithms such as those discussed in [15] and [16]. These algorithms and extensions are desirable for multi-user and commerce based implementations but are not required for a basic ACL based security policy as discussed above. 14. Extensions The theory and application described above is applicable to a broad class of problem domains within the area of distributed control. Furthermore, the fundamental design principles presented here are adaptable to other implementation mechanisms beyond device and server appliance systems. The particular areas of extension which are most promising are those relating to: a) Run-time type inference (RTTI) for Object-Based Distributed Memory Expires 10/99 [Page 11] WBDM April, 1999 b) Broadcast and publish-subscribe virtual domains. These consist of protocols defining a message to be sent to the server, with the server broadcasting successive response or update messages to a client. c) Device Driver Interface and/or Device/Kernel Interface for creating IO drivers (e.g. a TCP-based driver for a video-camera which generates frames, an NVRAM storage device, Disk, interface to boot and system parameters database). d) Learning of Visiting hosts, traffic patterns, etc. This could be as simple as adding host entries to a file or as elaborate as contacting hosts back and searching their HTTP server's virtual filesystem. e) Data Mining, Event correlation, Commerce, and agent learning framework. To further facilitate the implementation of distributed virtual environments, the MLC++ library [20] is fully interfaceable to this driver module for further extension and development of such hybrid and multi-strategy algorithms using Internet-acquired information as a data source. Many other applications beyond those described here are possible, including but not limited to Electronic commerce, Remote monitoring, Remote control, object-based application servers, distributed virtual machines, etc. These applications are left as an exercise to the developer. 15. References [1] RFC 1945 Hypertext Transfer Protocol -- HTTP/1.0 T. Berners-Lee, MIT/LCS,R. Fielding, UC Irvine,H. Frystyk, MIT/LCS [2] Work in Progress: HTTP-nG Architectural Model (W3C Working Draft 10 July 1998) http://www.w3.org/TR/WD-HTTP-NG-architecture/ Bill Janssen, Xerox PARC, Henrik Frystyk Nielsen, W3C,Mike Spreitzer, Xerox PARC [3] UTF-8 Character encoding. X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary Specification, Document Number: P316. This information also appears in ISO/IEC 10646, Annex P. [4] RFC 1122 Requirements for Internet hosts - communication layers. R.T. Braden. Oct-01-1989. [5] [Java API] Java API Documentation Version 1.02 (See `http://java.sun.com/products/jdk/1.0.2/api/'.) [6] [Java RMI] RMI - Remote Method Invocation; Sun Microsystems, 1997. (See `http://java.sun.com/products/jdk/1.1/docs/guide/rmi/index.html'.) Expires 10/99 [Page 12] WBDM April, 1999 [7] Birrell, A. D. & Nelson, B. J., "Implementing Remote Procedure Calls", XEROX CSL-83-7, October 1983. [8] Lefler, McKusick, Karels, Quarterman, "The Design and Implementation of the 4.3BSD Operating System", Addison-Wesley, 1989, P: 292 [9] RFC 1866 Hypertext Markup Language - 2.0 T. Berners-Lee, D. Connolly, November 1995 [10] RFC 2045,2046 Multipurpose Internet Mail Extensions (MIME) N. Borenstein, November 1996 [11] Bil Lewis, Daniel J. Berg, "Threads Primer -A Guide to Multithreaded Programming", Prentice Hall, 1996, P. 1-26,90 [12] W. Richard Stevens, "UNIX Network Programming", Prentice Hall, New Jersey, 1990 P. 261-302 [13] Brian W. Kernighan & Dennis M. Ritchie, "The C Programming Language", Bell Laboratories, Murray Hill, New Jersey, 1978. [14] [Applet Sandbox Model] The Java Security FAQ, Sun Microsystems, 1998 (See `http://www.javasoft.com/sfaq/'.) [15] RFC 2313,2437 PKCS 1: RSA Encryption Version 1-5. B. Kaliski. March 1998. [16] RFC 1928 SOCKS Protocol Version 5. M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas & L. Jones. April 1996. [17] WBDM Client/Server Architecture (See `http://www.gigabitnetworks.com/wbdm.1/doc/'.) [18] RFC 1227 SNMP MUX Protocol and MIB M. Rose. May 1991 [19] RFC 1215 A Convention for Defining Traps for use with the SNMP M. Rose March 1991 [20] R. Kohavi, D. Sommerfield, J. Dougherty, "Data Mining with MLC++." International Journal on Artificial Intelligence Tools, Vol 6. No. 4,1997. (See `http://www.sgi.com/Technology/mlc/docs/mlc96.ps.Z'.) 16. Authors' Addresses James F. Dougherty Phone: +1 408-229-2298 Fax: N/A Email: jfd@cs.stanford.edu Expires 10/99 [Page 13] WBDM April, 1999 APPENDIX-A - Reference Implementation The implementation includes Java and C source code for both the client and server application, the multiplexor stub API on both client and server, and a sample management Applet that manipulates the object entities described above in 11) Object Entities and Type System. It includes all of the features described above and demonstrates the ability to run server application code in C communicating with a Java applet which runs in the context of a web-page program executing in a Java-enabled browser. Note that the design provides: (i) lightweight client and server implementations (less than 2500 lines of Java and C code) (ii) Server code which runs native (e.g. other than requiring an embedded JVM) (iii) extensible base design for adaptation to more complex and hybrid systems and (iv) a thorough and complete implementation that only requires a TCP/IP protocol stack, thread library, and a BSD[8] socket-style interface to compile and run. Solaris, VxWorks Source code Downloadable from: http://gigabitnetworks.com/wbdm.1/ See Also: http://www.gigabitnetworks.com/wbdm.1/doc/ Coming Soon: Linux, Windows CE/NT/9X If you would like to Mirror any or all of this information via FTP or Web, please send email to jfd@cs.stanford.edu APPENDIX-B: Copyrights Certain copyrights should be attached to the source driver above. These are listed below. Web Based Device Manager (WBDM) Driver Copyright (C) 1999 James F. Dougherty, III (jfd@cs.stanford.edu) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,USA. Java and all Java-based trademarks and logos are trademarks or registered Trademarks of Sun Microsystems, Inc. in the United States and other Countries. Expires 10/99 [Page 14] WBDM April, 1999