Package gnu.cajo.utils

A set of common utilities used by either proxy, or server items.

See: Description

Class Summary

Class	Description
BaseItem	An optional base class for server objects.
BaseProxy	A standard abstract base class for proxy objects.
CodebaseServer	The standard mechanism to send proxies, and other complex objects to remote VMs.
ItemServer	These routines are used for server object construction.
MonitorItem	This class is used to instrument an object for invocation logging purposes.
Multicast	This class can listen for UDP multicasts over the network, as well as to send out UDP announcements.
ProxyLoader	This class is used to avoid having to load proxies into the VM runtime of the proxy server.
ZippedProxy	This class is used to transfer its internal proxy object as a zipped marshalled object (zedmob).

Package gnu.cajo.utils Description

A set of common utilities used by either proxy, or server items. As a general rule, do not compile all of the utility classes blindly; rather jar any classes resulting from the compilation of the proxy or server applications. As a rule, a proxy hosting VM is not required to have these classes in its classpath; therefore, the ones used from this package by a proxy application must be included in the proxy's codebase jar file.

Fundamentally, there are two entities; clients and servers. A server is a Virtual Machine which, at a minimum, exports one item, meaning a remotely invokable object implementing the Invoke interface. A server can also provide proxies; i.e. mobile item interfaces, to the server's local item objects (exported or not), which run inside the client's runtime. A client is a VM that makes use of a server's items and proxies, but need not export any of its own. The architecture readily supports the possibility of hybrid client/server VMs. Each VM can export as many items as it wants.

Items can transparently connect to other items across, logical, virtual or physical separation. This package seeks to establish the following roles between items:

An item is a control element of a system, it performs three major tasks:

• control system resources
• monitor system operation
• log system transactions

A proxy is a optional, item-specific, interface, designed to separate and manage the following functions:

• user input validation and feedback
• item output formatting and presentation
• localization and internationalization

Any item instance can invoke a transpparently local/remote method invocation on another. The invocation may or may not carry inbound data, and may or may not result in a synchronous response of data. A remote method invocation may also initiate an asynchronous operation in the receiver, resulting in a subsequent callback invocation from the receiver back to the client, at a later time.

When the items are remote; the overall network structure looks something like this:

 --------------         --------------
|  Server VM   |       |  Client VM   |
|  ----------  | TCP   |  ----------  |
| | Item     | | links | | Proxy    | |
| |----------| |       | |----------| |
| | http     | |<------| | codebase | |
| | callback | |<------| | notify   | |
| | notify   | |------>| | callback | |
|  ----------  |       |  ----------  |
 --------------         --------------

Note: Each outgoing TCP link consumes a corresponding anonymous return link, so the following port consumption realities for a server VM must be considered:

• Each item consumes 2 inbound ports permanently (http / callback)
• Each item consumes 1 outbound short-term port per client (codebase)
• Each item consumes 1 outbound session-term port per client (callback)

Therefore, it must be understood that since each connecting client will consume 2 dynamically allocated TCP ports, therefore no more than ~64k simultaneous clients could be served by one IP address; that is, assuming the host had no other servers. Therefore, for very high usage hosts, multiple physical machines, multiple network interfaces, or a multi-homed host, would become necessary.