 |
Claims  |
|
|
What is claimed is:
1. A method of operating a distributed computer system having a plurality
of distinct computers, the method comprising steps of:
a) in a first computer, storing viewer programs, each viewer program
enabling a user thereof to view data in objects of an associated data
type;
b) in said first computer, enabling a user to view data in a first object
having an associated first data type using a first one of said viewer
programs; said data in said first object including link data referencing a
second object of a second data type, said link data identifying a second
computer in which said second object is located;
c) in said first computer, enabling said user to select said link data;
e) said first computer responding to user selection of said link data by
establishing a first communication link between said first computer and
said second computer and initiating retrieval of said second object from
said second computer including retrieving data type information associated
with said second object;
f) said first computer, determining whether said viewer programs stored in
said first computer include a viewer program associated with said second
data type;
g) when said determination in step (f) is negative, determining whether a
viewer program associated with said second data type is stored in said
second computer;
h) when said determination in step (g) is positive,
h1) loading a copy of said viewer program associated with said second data
type into said first computer,
h2) executing a verification procedure on said copied viewer program to
determine whether said copied viewer program meets predetermined operand
stack usage criteria;
h3) when said determination is step h2 is positive, executing said copied
viewer program so as to enable said user to view said second object.
2. The method of claim 1, further including the steps of:
when said determination in step g is negative, determining whether a viewer
program associated with said second data type is stored in any of a
predefined set of other computers, and when such determination is
positive, performing steps h1 through h3.
3. The method of claim 1, further including the steps of:
when said determination in step h2 is negative, determining whether a
viewer program associated with said second data type is stored in any of a
predefined set of other computers, and when such determination is
positive, performing steps h1 through h3.
4. A method of operating a distributed computer system having a plurality
of distinct computers, the method comprising steps of:
a) in a first computer, storing viewer programs, each viewer program
enabling a user thereof to view objects of an associated data type;
b) in said first computer, enabling a user to select a reference to an
object located in a second computer;
c) said first computer responding to user selection of said reference by
establishing a first communication link between said first computer and
said second computer and initiating retrieval of said object from said
second computer including retrieving data type information associated with
said object;
d) in said first computer, determining whether said viewer programs stored
in said first computer include a viewer program associated with said
retrieved data type;
e) when said determination in step (d) is negative, determining whether a
viewer program associated with said retrieved data type is stored in said
second computer;
f) when said determination in step (e) is positive,
f1) loading a copy of said viewer program associated with said retrieved
data type into said first computer,
f2) executing a verification procedure on said copied viewer program to
determine whether said copied viewer program meets predetermined operand
stack usage criteria;
f3) when said determination in step f2 is positive, executing said copied
viewer program so as to enable said user to view said second object.
5. The method of claim 4, further including the steps of:
when said determination in step e is negative, determining whether a viewer
program associated with said second data type is stored in any of a
predefined set of other computers, and when such determination is
positive, performing steps f1 through f3.
6. The method of claim 4, further including the steps of:
when said determination in step f2 is negative, determining whether a
viewer program associated with said second data type is stored in any of a
predefined set of other computers, and when such determination is
positive, performing steps f1 through f3.
7. A method of operating a distributed computer system having a plurality
of distinct computers, the method comprising steps of:
a) in a first computer, storing a first library of viewer programs, each
viewer program enabling a user thereof to view objects of an associated
data type;
b) in said second computer, storing objects and a second library of viewer
programs, each viewer program in said first and second libraries of viewer
programs enabling a user of said second computer to view objects of an
associated data type;
c) in said second computer, enabling said user of said second computer to
select an object and determining said selected object's associated data
type;
d) in said second computer, determining whether said viewer programs stored
in said second computer include a viewer program associated with said
selected object's data type;
e) when said determination in step (d) is negative, determining whether a
viewer program associated with said selected object's data type is stored
in said first computer;
f) when said determination in step (e) is positive,
f1) loading a copy of said viewer program associated with said selected
object's data type into said second computer,
f2) executing a verification procedure on said copied viewer program to
determine whether said copied viewer program meets predetermined operand
stack usage criteria;
f3) when said determination in step f2 is positive, executing said copied
viewer program so as to enable said user to view said selected object.
8. The method of claim 7, further including the steps of:
when said determination in step e is negative, determining whether a viewer
program associated with said second data type is stored in any of a
predefined set of other computers, and when such determination is
positive, performing steps f1 through f3.
9. The method of claim 7, further including the steps of:
when said determination in step f2 is negative, determining whether a
viewer program associated with said second data type is stored in any of a
predefined set of other computers, and when such determination is
positive, performing steps f1 through f3.
10. A distributed computer system having a plurality of distinct computers,
comprising:
a first computer, including:
a first memory for storing objects and viewer programs, each stored object
including data type information associated with said each object; and
a second computer, including:
a second memory, distinct from said first memory, for storing viewer
programs, each viewer program enabling a user of said second computer to
view objects of an associated data type;
a user interface control program for enabling said user to select a
reference to one of said objects stored in said first memory of said first
computer; and
an inter-computer link control program for responding to user selection of
said object reference by establishing a first communication link between
said second computer and said first computer and initiating retrieval of
said one object from said first computer including retrieving data type
information associated with said object;
said user interface control program including viewer search instructions
for determining whether said viewer programs stored in said second
computer include a viewer program associated with said retrieved data
type, and, when said determination is negative, for attempting to locate a
viewer program associated with said retrieved data type in said first
computer; and
said inter-computer link control program including viewer downloading
instructions for loading a copy of said viewer program associated with
said retrieved data type into said second memory of said second computer
when said viewer search instructions locate in said first computer said
viewer program associated with said retrieved data type.
11. The system of claim 10,
said second computer further including
a verification procedure for determining whether said copied viewer program
meets predetermined operand stack usage criteria, and
program enabling instructions for enabling executing said copied viewer
program so as to enable said user to view said second object when said
verification procedure determines that said copied viewer program meets
said predetermined criteria.
12. A distributed computer system having a plurality of distinct computers,
comprising:
a first computer, including:
a first memory for storing a first library of viewer programs, each stored
object including data type information associated with said each object;
and
a second computer, including:
a second memory for storing objects and a second library of viewer
programs, each viewer program in said first and second libraries of viewer
programs enabling a user of said second computer to view objects of an
associated data type;
a user interface control program for enabling said user to select an object
and for determining said selected object's associated data type; and
a class loader, coupled to said second memory, said class loader including:
viewer search instructions for determining whether said viewer programs
stored in said second computer include a viewer program associated with
said selected object's data type, and, when said determination is
negative, for attempting to locate a viewer program associated with said
selected object's data type in said first computer; and
viewer downloading instructions for loading a copy of said viewer program
associated with said selected object's data type into said second computer
when said viewer search instructions locate in said first computer said
viewer program associated with said selected object's data type. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to the use of computer software on
multiple computer platforms which use distinct underlying machine
instruction sets, and more specifically to a method of verifying the
integrity of computer software obtained from a network server or other
source.
2. Prior Art
As represented generally in FIG. 1, in a typical prior art networked
computer system 100, a first computer 102 may download a computer program
103 residing on a second computer 104. In this example, the first user
node 102 will typically be a user workstation having a central processing
unit 106, a user interface 108, a primary memory 110 (e.g., random access
memory) for program execution, a secondary memory 112 (e.g., a hard disc)
for storage of an operating system 113, programs, documents and other
data, and a modem or other communication interface 114 for connecting to a
computer network 120 such as the Internet, a local area network or a wide
area network. The computers 102 and 104 are often called "nodes on the
network" or "network nodes."
The second computer 104 will often be a network server, but may be a second
user workstation, and typically would contain the same basic array of
computer components as the first computer.
In the prior art, after the first computer 102 downloads a copy of a
computer program 103 from the second computer 104, there are essentially
no standardized tools available to help the user of the first computer 102
to verify the integrity of the downloaded program 103. In particular,
unless the first computer user studies the source code of the downloaded
program, it is virtually impossible using prior art tools to determine
whether the downloaded program 103 will underflow or overflow its stack,
or whether the downloaded program 103 will violate files and other
resources on the user's computer.
A second issue with regard to downloading computer software from one
computer to another concerns transferring computer software between
computer platforms which use distinct underlying machine instruction sets.
There are some prior art examples of platform independent computer
programs and platform independent computer programming languages. What the
prior art lacks are reliable and automated software verification tools for
enabling recipients of such software to verify the integrity of
transferred platform independent computer software obtained from a network
server or other source.
Another aspect of the present invention concerns methods for automatically,
after a user selects an object or file to download from a remote location,
downloading software associated with object or file. For instance, there
is widely used feature of the Internet known as the "World Wide Web"
(WWW).
When reviewing a document on the Internet's World Wide Web (WWW), a page of
the document may contain references to other documents or to objects. A
user can access such other documents or objects by selecting a given
object via an associated hyperlink. Such selection is usually performed by
a user, in conjunction with a graphical user interface on a workstation
node, by depressing a button on a pointer device while using the pointer
device to point at a graphical image representing the hyperlink selection.
In response to selection of a hyperlink, the user's Web access program
will then open a connection to the server on which the referenced document
of object resides (as indicated by data embedded in the hyperlink in the
document or object currently being viewed), and downloads the referenced
document or object. However, if the downloaded document or object is of a
data type unknown to the user's Web access program, the user will be
unable to view or otherwise utilize the downloaded document.
When this happens, the user will often attempt to manually locate a viewer
for the downloaded document or object by looking through libraries of
programs on the server from which the document or object was retrieved, or
on other servers. If a viewer is found that is compatible with the user's
computer platform, the user may download the viewer and then execute it so
as to view the previously downloaded object. However, there are some
significant risks to the user associated with executing a viewer of
unknown origin. For instance, the downloaded viewer program may have
embedded "virus" programs that will compromise the integrity of the user's
computer, or the downloaded program itself may access resources and/or
destroy information on the user's computer, contrary to the user's wishes.
The present invention overcomes these difficulties by providing automatic
downloading of viewers for documents and objects and automatic integrity
verification of those programs before the downloaded viewer can be
executed.
SUMMARY OF THE INVENTION
The present invention is a "class loader" for retrieving (i.e.,
downloading) objects and object viewers from remote computer nodes, and
for invoking locally stored object viewers to view objects. When a user
selects an object to view, such as by using the hyperlink feature of the
World Wide Web, a conventional downloading of the referenced object is
initiated. The class loader of the present invention, however, utilizes
data type information received at the beginning of the object downloading
process to determine whether a viewer for the referenced object is
available on the user's workstation.
If an appropriate viewer is not locally available, the class loader
automatically locates an appropriate viewer on the server from which the
object is being downloaded, or from any other appropriate server known to
the user's workstation. The class loader downloads the located viewer and
then invokes a program verification procedure to verify the integrity of
the downloaded viewer before the viewer is executed. Once a viewer has
been verified, the viewer is added to the user's local viewer library,
downloading of the referenced object is completed, and execution of the
viewer to view the downloaded object is enabled.
If an appropriate viewer cannot be located, or the only viewer located does
not pass the verification procedure, downloading of the referenced object
is aborted.
The present invention verifies the integrity of computer programs written
in a bytecode language, to be commercialized as the OAK language, which
uses a restricted set of data type specific bytecodes. All the available
source code bytecodes in the language either (A) are stack data consuming
bytecodes that have associated data type restrictions as to the types of
data that can be processed by each such bytecode, (B) do not utilize stack
data but affect the stack by either adding data of known data type to the
stack or by removing data from the stack without regard to data type, or
(C) neither use stack data nor add data to the stack.
The present invention provides a verifier tool and method for identifying,
prior to execution of a bytecode program, any instruction sequence that
attempts to process data of the wrong type for such a bytecode or if the
execution of any bytecode instructions in the specified program would
cause underflow or overflow of the operand stack, and to prevent the use
of such a program.
The bytecode program verifier of the present invention includes a virtual
operand stack for temporarily storing stack information indicative of data
stored in a program operand stack during the execution a specified
bytecode program. The verifier processes the specified program by
sequentially processing each bytecode instruction of the program, updating
the virtual operand stack to indicate the number, sequence and data types
of data that would be stored in the operand stack at each point in the
program. The verifier also compares the virtual stack information with
data type restrictions associated with each bytecode instruction so as to
determine whether, during program execution, the operand stack would
contain data inconsistent with the data type restrictions of the bytecode
instruction, and also determines whether any bytecode instructions in the
specified program would cause underflow or overflow of the operand stack.
To avoid detailed analysis of the bytecode program's instruction sequence
flow, and to avoid verifying bytecode instructions multiple times, all
points (called multiple-entry points) in the specified program that can be
can be immediately preceded in execution by two or more distinct bytecodes
in the program are identified. In general, at least one of the two or more
distinct bytecodes in the program will be a jump/branch bytecode. During
processing of the specified program, the verifier takes a "snapshot" of
the virtual operand stack immediately prior to each multiple-entry point
(i.e., subsequent to any one of the preceding bytecode instructions),
compares that snapshot with the virtual operand stack state after
processing each of the other preceding bytecode instructions for the same
multiple-entry point, and generates a program fault if the virtual stack
states are not identical.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in and form a part of
this specification, illustrate embodiments of the invention and, together
with the description, serve to explain the principles of the invention,
wherein:
FIG. 1 depicts two computers interconnected via a network.
FIG. 2 depicts two computers interconnected via a network, at least one of
which includes a secondary storage device for storing multiple copies of a
source program in different executable forms.
FIG. 3 depicts two computers interconnected via a network, at least one of
which includes a bytecode program verifier and class loader in accordance
with the present invention.
FIG. 4 represents a flow chart of the loading process for accessing a
bytecode program and viewer stored in a remote server according to the
preferred embodiment of the present invention.
FIG. 5 depicts data structures maintained by a bytecode verifier during
verification of a bytecode program in accordance with the present
invention.
FIGS. 6, 6A-G represents a flow chart of the bytecode program verification
process in the preferred embodiment of the present invention.
FIG. 7 represents a flow chart of the bytecode program interpreter process
in the preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Reference will now be made in detail to the preferred embodiments of the
invention, examples of which are illustrated in the accompanying drawings.
While the invention will be described in conjunction with the preferred
embodiments, it will be understood that they are not intended to limit the
invention to those embodiments. On the contrary, the invention is intended
to cover alternatives, modifications and equivalents, which may be
included within the spirit and scope of the invention as defined by the
appended claims.
Referring now to a distributed computer system 200 as shown in FIG. 2, a
first computer node 202 is connected to a second computer node 204 via a
computer communications network 216 such as the Internet. The first
computer node 202 includes a central processing unit 206, a user interface
208, primary memory (RAM) 210, secondary memory (disc storage) 212, and a
modem or other communication interface 214 that connects the first
computer node 202 to the computer communication network 216. The disc
storage 212 stores programs for execution by the processor 206, as well as
data files and other information.
The second computer node 204, assumed here to be configured as a file or
other information server, includes a central processing unit 218, a user
interface 220, primary memory (RAM) 222, secondary memory (disc storage)
224, and a modem or other communication interface 226 that connects the
second computer node to the computer communication network 216. The disc
storage 224 includes a file and/or object directory 228 (sometimes called
a disc directory or catalog) for locating information stored in secondary
memory 224, objects 230, a viewer library 232 and other programs 234 for
execution by the processor 218 and/or distribution to other computer
nodes.
The first and second computer nodes 202 and 204 may utilize different
computer platforms and operating systems 236, 237 such that object code
programs executed on either one of the two computer nodes cannot be
executed on the other. For instance, the server node 204 might be a Sun
Microsystems computer using a Unix operating system while the user
workstation node 202 may be an IBM compatible computer using an 80486
microprocessor and a Microsoft DOS operating system. Furthermore, other
user workstations coupled to the same network and utilizing the same
server 204 might use a variety of different computer platforms and a
variety of operating systems.
In the past, a server 204 used for distributing software on a network
having computers of many types would store multiple distinct libraries
(e.g., multiple, distinct viewer libraries 232) of software for each of
the distinct computer platform types (e.g., Unix, Windows, DOS, Macintosh,
etc.). Accordingly, in order to support the needs of the various system
users, a server would be required to store both a plurality of versions of
the same computer program (238 and 239) as well as a plurality of object
viewers (241 and 243), one for each computer platform type. However, using
the present invention, many varied users can be supported through the
distribution of a single bytecode version of the program.
Referring now to FIG. 3, a distributed computer system 250 incorporating
the teachings of the present invention is shown. A first computer node 252
is connected to a second computer node 254 via a computer communications
network 266 such as the Internet. Again, just as in the prior art, the
first and second computer nodes 252 and 254 may utilize different computer
platforms and operating systems 255, 256 such that object code programs
executed on either one of the two computer nodes cannot be executed on the
other. For instance, the server node 254 might be a Sun Microsystems
computer using a Unix operating system while the user workstation node 252
may be an IBM compatible computer using an 80486 microprocessor and a
Microsoft DOS operating system as was described above in conjunction with
FIG. 2. The first computer node 252 includes a central processing unit
257, a user interface 258, primary memory (RAM) 260, secondary memory
(disc storage) 262, and a modem or other communication interface 264 that
connects the first computer node 252 to the computer communication network
266. The disc storage 262 stores programs for execution by the processor
257, at least one of which is a bytecode program 267 which is of
executable form. For the purposes of this description, it will be assumed
that the first computer node 252 receives the bytecode program 267 from
the second computer node 254 via the computer communications network 266,
the details of which will be described in greater detail below in
conjunction with the class loader.
In the preferred embodiment, the bytecode program is written as an OAK
application, which when compiled or interpreted will result in a series of
executable instructions. A listing of all the source code bytecode
instructions in the OAK instruction set is provided in Table 1. The OAK
instruction set is characterized by bytecode instructions that are data
type specific. Specifically, the OAK instruction set distinguishes the
same basic operation on different primitive data types by designating
separate opcodes. Accordingly, a plurality of bytecodes are included
within the instruction set to perform the same basic function (for example
to add two numbers), with each such bytecode being used to process only
data of a corresponding distinct data type. In addition, the OAK
instruction set is notable for instructions not included. For instance,
there are no "computed goto" instructions in the OAK language instruction
set, and there are no instructions for modifying object references or
creating new object references (other than copying an existing object
reference). These two restrictions on the OAK instruction set, as well as
others, help to ensure that any bytecode program which utilizes data in a
manner consistent with the data type specific instructions in the OAK
instruction set will not violate the integrity of a user's computer
system.
In the preferred embodiment, the available data types are integer, long
integer, short integer (16 bit signed integer), single precision floating
point, double precision floating point, byte, character, and object
pointer (sometimes herein called an object reference). The "object
reference" data type includes a virtually unlimited number of data
subtypes because each "object reference" data type can include an object
class specification as part of the data type. In addition, constants used
in programs are also data typed, with the available constant data types in
the preferred embodiment comprising the data types mentioned above, plus
class, fieldref, methodref, string, and Asciz, all of which represent two
or more bytes having a specific purpose.
The few bytecodes that are data type independent perform stack manipulation
functions such as (A) duplicating one or more words on the stack and
placing them at specific locations within the stack, thereby producing
more stack items of known data type, or (B) clearing one or more items
from the stack. A few other data type independent bytecode do not utilize
any words on the stack and leave the stack unchanged, or add words to the
stack without utilizing any of the words previously on the stack. These
bytecodes do not have any data type restrictions with regard to the stack
contents prior to their execution, but all modify the stack's contents in
a totally predictable manner with regard to the data types of the items in
the stack. As a result, the number of operands in the stack and the data
type of all operands in the stack can be predicted (i.e., computed) with
100% confidence at all times.
The second computer node 254, assumed here to be configured as a file or
other information server, includes a central processing unit 268, a user
interface 270, primary memory (RAM) 272, secondary memory (disc storage)
274, and a modem or other communication interface 276 that connects the
second computer node to the computer communication network 266. The disc
storage 274 is comprised of a directory 280, objects 282 including a first
object 283, a viewer library 284 and programs 286 for execution by the
processor 268 and/or distribution to other computer nodes, at least one of
which is the bytecode program 267 for transfer to computer node 252.
As shown in FIG. 3, the first computer node 252 stores in its secondary
memory 262 a class loader program 296 for retrieving (i.e., downloading)
objects and object viewers from other computer nodes, and for invoking
locally stored object viewers to view objects. The class loader 296 also
automatically verifies (at the site of the end user's workstation node)
downloaded object viewers to verify the integrity of each viewer before it
is executed by each user.
For the purposes of this document, an "object" that may be "viewed" using
an associated viewer can be either (A) a data-only type of object, such as
a file other data structure that contains data of a specific type or
format, such as JPEG, GIF, MPEG, or MPEG2 data, without having any
embedded method or software, or (B) a method-storing object, such as a
file or other data structure that includes one or more embedded methods,
and optionally data as well. For instance, distinct viewers may be needed
for viewing data-only objects that store distinct image data types, such
as JPEG and GIF, and for viewing data-only objects that store distinct
video program data types such as MPEG and MPEG2. Other examples might be
distinct viewers for viewing charts of data, viewers with built-in data
decryption software for viewing encrypted data (when the decryption key is
known to the user), and so on.
In addition, distinct viewers may be needed for method-storing objects
using different internal program types. For instance, different internal
program types in various method-storing objects might use distinct
scripting languages or might assume the availability of different
libraries of utility programs, thereby requiring different viewers.
A "viewer" (sometimes called an interpreter) decodes data and/or
instructions in a specified object, and generally performs whatever
computations and operations are needed to make objects of a particular
data type or class usable. In the present invention, such object viewers
are bytecode programs, written in a source code bytecode language so that
the integrity of each object viewer can be independently verified by an
end user through execution of a bytecode program verifier 240. Bytecode
program verification is discussed in more detail below.
It should be noted that a distributed computer system 250 may include
platform independent object viewers in accordance with the present
invention as well as other object viewers which are not platform
independent and which cannot be verified using the bytecode program
verifier 240 and class loader 296 tools of the present invention. In such
a hybrid system, the automated viewer integrity verification benefits of
the present invention will be provided for bytecode viewer programs, but
not for other viewer programs.
The class loader 296 is an executable program for loading and verifying
objects and object viewers from a remote server. When reviewing a document
on the Internet's World Wide Web (WWW) for example, a page of the document
may contain references to other documents or to objects. A user can access
such other documents or objects by selecting a given object via an
associated hyperlink. Such selection is usually performed by a user, in
conjunction with a graphical user interface on a workstation node, by
depressing a button on a pointer device while using the pointer device to
point at a graphical image representing the hyperlink selection.
During the selection process, the document or object which is currently
being viewed may contain references to other documents or objects,
including some having a data type which is unknown to the user's
workstation. The class loader of the present invention is utilized to both
locate a viewer associated with a "foreign" data type, and to verify
program integrity of all downloaded bytecode programs prior to their
execution by the user.
The class loader 296 performs three primary functions. First the class
loader checks the data types of downloaded objects [and their associated
bytecode programs] to determine if the user workstation has an associated
viewer in a "viewer library" 298 in its own local storage 262. Secondly,
if the class loader can not locate the appropriate viewer, it executes a
search routine at both the source server and other servers it has
knowledge of to locate and download the proper viewer. If no viewer can be
located, then the object and/or bytecode program which has been down
loaded is rejected for want of an appropriate viewer. Finally, upon
locating the appropriate viewer at a remote source, the class loader
invokes execution of a bytecode verifier 240 to check the downloaded
viewer prior to the execution of viewer in conjunction with a bytecode
program interpreter 242 or compilation by a bytecode program compiler 244.
After verification, the downloaded viewer may be stored in the user's
local viewer library 298.
Referring now to FIGS. 3 and 4 and Appendix 1, the execution of the class
loader program 296 will be described in detail for retrieving a bytecode
program via an associated object. Appendix 1 lists a pseudocode
representation of the class loader program. The pseudocode used in
Appendix 1 is, essentially, a computer language using universal computer
language conventions. While the pseudocode employed here has been invented
solely for the purposes of this description, it is designed to be easily
understandable by any computer programmer skilled in the art.
As shown in FIG. 4, the user workstation 252 begins a download process by
opening (304) a connection to a server 254 which contains an object 283 to
be downloaded. The class loader 296 initiates (306) the transfer of the
object bytecode program by hyperlink selecting the object, whereupon the
server 254 transfers a "handle" for the referenced object to the user
workstation 252. The handle is retrieved prior to the body of the
referenced object and contains information concerning properties of the
referenced object, including the object's data type (sometimes called the
object class).
A first check (308) is made to determine if the data type associated with
the object to be retrieved is known to the user's system. Specifically,
the class loader searches a viewer library 298 resident in the secondary
storage 262 of the user workstation 252 to see if an appropriate viewer
for objects of the determined data type is accessible. The viewer library
298 includes a listing of all of the data type viewers which are currently
accessible by the user workstation and their appropriate locations in
memory. In this way, the class loader pre-processes the object to be
downloaded during the initial handshake in order to determine
compatibility with the user workstation platform prior to the actual
downloading of the body of the referenced object. If an appropriate viewer
is located, then the class loader completes (310) the downloading of the
referenced object.
If an appropriate viewer is not located within the viewer library 298,
indicating that the selected object is of a data type which is unfamiliar
to the user workstation 252, the class loader executes a search for an
appropriate viewer. In most circumstances the first place to look for an
appropriate viewer is the same server on which the selected object is
stored. Thus, the class loader opens (312) a second connection to the same
server which is the source of the referenced object and requests (314) a
viewer for the indicated data type. If the server contains the appropriate
viewer, the viewer is downloaded (315) into the user's workstation.
Upon completion of the download, if the downloaded viewer is a bytecode
program (316) the class loader will initiate a verification (317) of the
viewer program by invoking the bytecode program verifier 240. The bytecode
program verifier 240 is an executable program which verifies operand data
type compatibility and proper stack manipulations in a specified bytecode
(source) program prior to the execution of the bytecode program by the
processor 257. The operation of the bytecode verifier program 240 will be
described in greater detail below. If the verification is successful
(318), the server searcher will store (319) the verified object viewer in
the viewer library 298 and update the directory in the library to reflect
the availability of the new data type viewer. If the verification is
unsuccessful the downloaded viewer will be deleted (320).
Some embodiments of the present invention allow for the automatic
downloading and use of both verifiable and non-verifiable object viewers.
In those embodiments, after downloading an object viewer (315), if the
downloaded object viewer is not a bytecode program (316), a determination
is made (321) whether or not to accept the object viewer. For example, the
user may be asked whether or not accept the object viewer, or a default
decision to accept or not accept such object viewers may be included a
configuration file. If the non-verifiable object viewer is accepted, it is
stored in the viewer library (319), and if it is not accepted the
downloaded viewer is deleted (320).
If steps 308 and 314 fail to locate a viewer suitable for use with the
selected object, because neither the server nor the user workstation
contains an appropriate viewer, the class loader expands its search to
include other server sites or remote user workstations (e.g., a known
server list 327) known to the user's workstation (steps 322 and 323).
Referring again to FIG. 3, a second server 324 is shown including a
secondary storage 325 having a viewer library 326. If the appropriate
viewer is located in the viewer library 326 of the second server 324, then
the class loader downloads and verifies the viewer program according to
steps 315-321 above. The class loader repeats this process, checking
alternate servers until all known resources are exhausted or an
appropriate viewer is located and verified. Finally, if no appropriate
viewer can be located, downloading of the referenced object is aborted and
a user message is generated to inform the user that a viewer for the
referenced object could not be located (328).
As indicated above, in the event an appropriate object viewer was already
stored in the viewer library 298 on the user's workstation (308) or was
successfully downloaded, verified and added to the user's viewer library,
the loading of the selected object is completed (310). If the downloaded
object includes one or more embedded bytecode programs (330 and is
therefore a method-storing object, the bytecode programs in the downloaded
object are verified (332) by invoking execution of the bytecode verifier
on those embedded programs. If the verifier generates a "success" return
code after processing the embedded programs (334), then the downloaded
object is viewed with the associated object viewer (335). If the verifier
aborts its processing of the embedded program due to detection of a
program that does not conform to the verifier's requirements (334), the
downloaded object is deleted (336) and an appropriate user message is
generated.
In the event that the downloaded object does not include embedded bytecode
programs (330), steps 332-334 are skipped and the object is viewed with
the appropriate viewer (335).
Referring again to FIG. 3, the first computer node 252 also stores in its
secondary memory 262 a bytecode verifier program 240 for verifying the
integrity of specified bytecode programs and a bytecode interpreter 242
for executing specified bytecode programs. Alternately, or in addition,
the first computer node 252 may store a bytecode compiler 244 for
converting a verified bytecode program into an object code program for
more efficient execution of the bytecode program than by the interpreter
242.
The bytecode verifier 240 is an executable program which verifies operand
data type compatibility and proper stack manipulations in a specified
bytecode (source) program prior to the execution of the bytecode program
by the processor 257 under the control of the bytecode interpreter 242 (or
prior to compilation of the bytecode program by compiler 244). Each
bytecode program 267 (including the downloaded object verifier) has an
associated verification status value 302 that is initially set to False
when the program is downloaded from another location. The verification
status value 302 for the program is set to True by the bytecode verifier
240 only after the program has been verified not to fail any of the data
type and stack usage tests performed by the verifier 240.
The Bytecode Program Verifier
Referring now to FIG. 5, the execution of the bytecode program verifier 240
will be explained in conjunction with a particular bytecode program 340.
The verifier 240 uses a few temporary data structures to store information
it needs during the verification process. In particular, the verifier 240
uses a stack counter 342, a virtual stack 344, a virtual local variable
array 345, and a stack snapshot storage structure 346.
The stack counter 342 is updated by the verifier 240 as it keeps track of
the virtual stack manipulations so as to reflect the current number of
virtual stack 344 entries.
The virtual stack 344 stores data type information regarding each datum
that will be stored by the bytecode program 340 in the operand stack
during actual execution. In the preferred embodiment, the virtual stack
344 is used in the same way as a regular stack, except that instead of
storing actual data and constants, the virtual stack 344 stores a data
type indicator value for each datum that will be stored in the operand
stack during actual execution of the program. Thus | | |
