Aqua Phoenix
     >>  Software >>  SunRay  


2. Sun Ray Boot

A Sun Ray Thin Client does not have the ability to store configuration data besides firmware. Hence, the Sun Ray is truly a "dumb terminal" - it has no means of knowing what Sun Ray server to connect to once the power cable is plugged in.

The Sun Ray relies on a specific network protocol and a series of automatic configuration steps to figure out what Sun Ray Server to connect to. The protocol used is DHCP (Dynamic Host Configuration Protocol). It tends to be used in a network environment where computers need not be configured for a specific set of network parameters (IP address, host name, gateway, name servers, etc.), but instead receive these parameters automatically when plugged into the network.

Via DHCP, a Sun Ray Thin Client is able to receive necessary network information, such as its own IP address and the Sun Ray Server IP address, to name the most important parameters. Once the Sun Ray Thin Client knows these values, it is able to connect to and communicate with the Sun Ray Server. Beyond this initial setup which occurs on powering on the unit, the Sun Ray Thin Client and Sun Ray Server communicate with a variety of protocols and services to maintain the current session.

The Sun Ray Server software includes a DHCP service, which delivers the necessary information to all of the Sun Ray Thin Clients on the same subnet. This DHCP service is capable of supplying dynamically allocated IP addresses from a pool specified in the Sun Ray Server software configuration, as well as supplying Sun Ray specific information.

While there is only one type of DHCP reply that the Sun Ray Thin Client accepts, the DHCP reply can be decomposed into 2 parts:

  1. Standard DHCP fields: This includes values assigned by the DHCP server, e.g. the client's IP address, a Gateway IP address, a Host Name, etc.
  2. Vendor-specific DHCP field: This includes values that Sun has invented and they are only applicable to Sun hardware, e.g. the Sun Ray Server IP, the Log Host IP, etc.

The DHCP messages carrying Standard and Vendor-specific fields can be incorporated into ONE reply or SEVERAL replies. This becomes very important when dividing the responsibilities on a distant network that has not necessarily been designed for Sun Ray Thin Clients.

2.1 DHCP Message Separation

While a Sun Ray Thin Client requires information from the standard DHCP fields (its IP address, Gateway IP, etc.) as well as from the Vendor-specific DHCP field (SunRay Server IP, etc.), it is not necessary for the SunRay to receive all of this data in one packet. In fact, the data can not only be sent in separate DHCP responses, but also from separate DHCP servers. The implications of this observation are important to the operation of a Sun Ray Thin Client that is not on the same subnet as the Sun Ray Server.

When a Sun Ray Thin Client is connected to a network for which a DHCP server has been configured, the Sun Ray Thin Client receives it IP address and other standard network parameters from that server. This DHCP server must not have any knowledge about or be configured for Sun Ray Thin Clients in order to serve network parameters to a Sun Ray Thin Client.

To serve the necessary additional Vendor-specific Options to the Sun Ray Thin Client, routers can be configured to redirect the DHCP request to the actual Sun Ray Server, or the existing DHCP Server can be configured to serve these parameters. Both of these options can be time-consuming, technically involved, or impossible in an institutionally maintained network. However, because of DHCP response and response server separation, one can set up a small DHCP server on the subnet of the Sun Ray Thin Client, and serve the Vendor-specific Options specifically for one or more Sun Ray Thin Clients. This does, of course, require access to one machine on the network that will be running this separate DHCP server. This solution, a working Perl Script, and its implications is discussed later.