Internet DRAFT - draft-dougherty-wbdm
draft-dougherty-wbdm
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:38:17 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 29 Apr 1999 13:17:29 GMT
ETag: "2e6c91-96d7-37285be9"
Accept-Ranges: bytes
Content-Length: 38615
Connection: close
Content-Type: text/plain
Internet Draft James Dougherty (jfd@cs.stanford.edu)
Internet Engineering Task Force
Expiration: October, 1999 April, 1999
Web Based Device Management (WBDM)
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 an application-level network driver designed to allow a
general purpose client program to execute out of a web-browser.
This specification uses the technology to manage a node, or network
enabled device.
WBDM provides a reference implementation for this distributed
application environment through the use of Java (TM) based client
code and an ANSI C server implementation portable to any operating
environment which supports threads (lightweight processes with a
single, shared, address space), a TCP/IP stack, and BSD-style
sockets.
WBDM embeds a Java (TM) client program in a server-side application
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
Expires 10/99 [Page 1]
WBDM April, 1999
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. Furthermore, WBDM is extensible to any other type
system using the primitives defined within.
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.
Expires 10/99 [Page 2]
WBDM April, 1999
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 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.
Expires 10/99 [Page 3]
WBDM April, 1999
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.
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.
All HTML Java Applet tags should support the dynamic expansion of
the following 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)
Expires 10/99 [Page 4]
WBDM April, 1999
as in the following HTML statements:
<APPLET CODEBASE="/" CODE="ConsoleGUI" WIDTH=500 HEIGHT=300>
<PARAM NAME = "HOST" VALUE = "%h">
<PARAM NAME = "PORT" VALUE = "%p">
</APPLET>
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.
Note that in the context of retrieving hostname and port, one could
simply use the getCodeBase().getHost() and getCodeBase().getPort()
methods of the Java (TM) Applet and URL classes to get the hostname
and port of the management server, however, the intention is to
provide for a more general server-generated Dynamic HTML parameter
passing mechanism which uses the Applet.getParameter() method. This
allows extension for other dynamic properties (e.g. a filename,
memory address, etc). Furthermore, this ensures that once a dynamic
HTML template is created, it need not be edited frequently since
doing so will rebuild the ROM filesystem.
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).
Expires 10/99 [Page 5]
WBDM April, 1999
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.
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.
<INTEGER>:= [0-9]+
<STRING> := [0-9a-zA-Z]+
<LIST> := <STRING> : <LIST>
:= <STRING>
<ATTRVALUE> := <STRING> "=" <STRING>
:= <STRING> "=" <LIST>
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.
Expires 10/99 [Page 6]
WBDM April, 1999
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 endpoint port (80) which
simplifies firewall and client requirements. Note also that a
persistent HTTP connection must be maintained by the client to
minimize client processing and connection establishment overhead,
as well TCP traffic.
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.
Expires 10/99 [Page 7]
WBDM April, 1999
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)
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
Expires 10/99 [Page 8]
WBDM April, 1999
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:
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
Expires 10/99 [Page 9]
WBDM April, 1999
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.
a) NETWORK CONFIGURATION (NetworkControl)
0) NAME: <ATTRVALUE> - official DNS name of this system.
1) PORT: <INTEGER> - TCP/IP service port.
2) IPADDR: <ATTRVALUE> - IP address in a.b.c.d notation.
3) NETMASK: <STRING> - Network subnet mask in a.b.c.d notation.
4) MACADDR: <STRING> - Ethernet or station hardware address.
5) ROUTES: <LIST> - Network routes: a.b.c.d notation, default
routes are suffixed with "*".
6) ADMIN: <STRING> - Administrator email address.
7) DOMAIN: <STRING> - Official Domain name of this system.
8) NSLIST: <LIST> - List of nameservers in a.b.c.d notation.
*) USER DEFINED <ANY>
b) SYSTEM INFORMATION (System Control)
0) UPTIME: <STRING> - Date which system was booted or reset.
1) REQUESTS: <STRING> - Number of IO requests.
2) ERRORS: <STRING> - Number of IO errors.
*) USER DEFINED <ANY> - any other atomic or aggregate type.
c) ACCESS CONTROL
0) HOSTSALLOW <LIST> - List of IP addresses allowed access.
* USER DEFINED <ANY>
d) EVENTS
*) USER DEFINED. <ANY> - usually, a string with some information.
e) Objects
*) USER DEFINED. <ANY> - 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
Expires 10/99 [Page 10]
WBDM April, 1999
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. Where applicable, ANSI C interfaces are provided to
further facilitate portability:
a) Lightweight Processes or Threads [11]
- [Task Creation]
- [Task Deletion]
- [Task Syncronization]
b) BSD-style Socket Interface [12]
- socket()
- listen()
- bind()
- accept()
- setsockopt()
c) BIND or BSD-style Resolver library
- gethostbyaddr()
- gethostbyname()
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.
Expires 10/99 [Page 11]
WBDM April, 1999
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
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. Note that in order to
implement many of the aforementioned features, a local file
system (which may be based on mechanical storage devices) is
desirable. Since this is beyond the scope of this specification,
these applications and extensions 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
Expires 10/99 [Page 12]
WBDM April, 1999
[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'.)
[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'.)
Expires 10/99 [Page 13]
WBDM April, 1999
16. Authors' Addresses
James F. Dougherty
Phone: +1 408-229-2298
Fax: N/A
Email: jfd@cs.stanford.edu
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.
Expires 10/99 [Page 14]
WBDM April, 1999
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 15]
WBDM April, 1999
