JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Remote Administration Daemon Developer Guide     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Concepts

3.  Abstract Data Representation

4.  libadr

5.  Client Libraries

6.  Module Development

7.  rad Best Practices

A.  rad Binary Protocol

Overview

Common Data Formats

Operations

Errors

Time

Object Names

ADR Data

ADR types

Interface Definitions

Connection Initialization

Messages

Operations

INVOKE Operation

GETATTR Operation

SETATTR Operation

LOOKUP Operation

DEFINE Operation

LIST Operation

SUB and UNSUB Operations

Messages

Normal communication consists of an asynchronous exchange of messages: REQUESTs from the client to the server, RESPONSEs from the server to the client, and EVENTs from the server to the client.

A REQUEST is the rad equivalent of a low-level remote procedure call. It consists of a client-selected, non-zero serial number, an operation code, and an opaque, operation-specific, variable-length payload.

Table A-36 REQUEST

Field Name
Length
Type
Description
serial
8
hyper
Client-specified serial number
opcode
4
OP-CODE
Operation code (see Operations)
payload
Varies
opaque<>
Request payload

The server will respond to every REQUEST with a RESPONSE. A RESPONSE consists of the serial number of the corresponding REQUEST, an error code, and a response payload. If REQUEST succeeded, the error code will be EC-OK and the payload will contain the operation-defined payload data. Otherwise, the error code will reflect the type of failure and the payload will contain either the protocol-defined or object-defined error payload data.

Table A-37 RESPONSE

Field Name
Length
Type
Description
serial
8
hyper
Serial number of REQUEST
error
4
ERROR-CODE
Error code (see Errors)
payload
Varies
opaque<>
Response payload

The rad protocol does not require the client to wait for a RESPONSE before sending another REQUEST. However, the server implementation might place limits on the number of outstanding requests that can be handled simultaneously. A client with an outstanding REQUEST must assume that a subsequent REQUEST will block until the RESPONSE from the outstanding REQUEST is read.

A client may (through a REQUEST) subscribe to asynchronous event sources. When an event occurs, the server will send an EVENT message to the client. An EVENT message will include the object ID of the source object, the time of the event, the name of the event, and an event-specific opaque payload. An EVENT message is distinguished from a RESPONSE by having a serial number of 0.

Table A-38 EVENT

Field Name
Length
Type
Description
serial
8
hyper
0
source
8
hyper
ID of generating object
sequence
8
hyper
Sequence number of event
timestamp
12
TIME-DATA
Time of event
name
Varies
string<>
Event name
payload
Varies
opaque<>
Event payload