The EJB server is divided into five parts:
These parts are illustrated in the diagram below.
Each of these parts is a full member of the Ensemble group, which means that any particular instance of the server application may have only a partial collection of parts. For instance, if your machine does not have a cdrom drive, it would be pointless to include a cdrom driver. All of these members execute as part of the same process (the cdda process), except for the cdrom and play members, which have stubs that execute in priviledged mode.
The cdrom driver is itself split into two parts: a part that belongs to the cdda application, and the subprocess cdserver that executes in priviledged mode. Execution of the subprocess is automatic, and it is started whenever the server itself is running. In Linux, the cdserver process needs raw access to the /dev/cdrom device (as well as the /dev/sg device for SCSI drives). Since these drives are usually readable only by root, the cdserver program is installed setuid root.
Once the cdserver process starts, it resumes operation in user mode, and communicates with the cdda server using a shared memory buffer. The use of a shared memory buffer improves operation of the driver. Since an io operation is not necessary to transfer data from the cdserver process, the scheduling behavior is much better than an implementation that would use standard Unix pipes to communicate the audio data.
The audio driver works on a similar principle as the cdrom driver. When the play driver intends to send audio data to the sound car, it starts execution of a playserver subprocess. Unlike the cdrom driver, this subprocess runs only during playback. This allows the /dev/dsp device to be used by other programs.
The file driver manages audio storage in a single directory. File are stored in a directory named with a hash number extracted from the CD data, and each directory contains an index for the CD (containing the track information), and files storing the audio data for each track. These files are not stored in a standard format (like .wav), but there is efficient access to the audio data through the file driver.
If there is more than one directory to be managed on a machine, multiple file drivers are present in the cdda server.
The radio and collection manage the audio database described in the section on directories and radios. Each user manages a “radio station.” All users listening to the same station receive the same playback, and the radio server manages the copying. The radio server acts as a proxy device. The user requests playback from the radio device, which forwards the request to the audio storage device containing the audio information. This presents the appearance that audio data is copied through the radio, and all users listening to that radio receive the same data.
In fact, the radio does not copy the data, it just copies the control commands, and the data is copied at the source device.
The radio server also manages the collection database, which contains collections users have constructed for grouping audio data (independent of the location of the physical audio data). Each radio provides the ability to play bck collections, and the switching between multiple physical audio sources is managed by the radio device.
The final component of the cdda server is the server driver, which presents a connection point for serving client requests. The server waits for connections on a socket. Once a connection is established, the server driver performs the protocol conversion from the socket protocol to the Ensemble group protocol.