Networking / Beginners

---

COBRA Communications

COBRA's GIOP is defined along with COBRA by the OMG. GIOP is a generic object exchange protocol designed to be mapped onto any connection-oriented transport protocol. The OMG lists the objectives of GIOP as simplicity, scalability, low cost, generality, and architectural neutrality. GIOP attempts to achieve these goals by defining a set of assumptions about the underlying transport mechanism, messages to carry the data and data manipulation requests across the transport mechanism, and a list of syntaxes for the representation of IDL data types within the messages.

The GIOP common data representation (CDR) defines how objects and data are encoded within messages. There are several key points to note:

• All data types are aligned on their natural boundaries to make it easier for applications to read and write data to messages. This has the obvious consequence that messages may be larger than strictly required, but makes application implementation more simple. Note that as data objects are placed in a message, they may need to be prepadded to bring the message up to the correct byte offset.
• Integers are supplied in messages in the sender's native format. This differs from the normal process in which all integers are transferred in "wire format" with the most significant byte first. Again, this allows for a simpler implementation- a sender never has to manipulate data before placing it in a message. A flag in each GIOP message indicates the sender's integer format and the receiver need only manipulate the data from a message if its own integer format is different.
• Other encodings (such as ASN.1 for SNMP requests) may be encapsulated as octet strings (that is, transparent streams of bytes) within the CDR.
• The CDR includes a construct called an indirection that allows one part of a message to point to data in another part of the message. This enables a degree of compression so that repeated data need only be present in the message once.

GIOP is a client-server protocol. The client is responsible for initiating a connection (using the underlying transport mechanism) with the server, and initiating the communications. In early versions of GIOP the server was not allowed to send request messages-it could only respond to requests from the client so that if two nodes wished to operate on each other's data objects it was necessary to maintain two connections between them. Although this added some simplicity to implementations in which only a unidirectional service was needed, the limitation has been relaxed in later versions of GIOP to allow bidirectional request exchanges on a single connection with the distinction of client and server diminished to connection management.

All GIOP messages begin with a common header. The fi rst 4 bytes contain the magic cookie "GIOP" encoded in ASCII. The next two fi elds give the version number-the current version is 1.3, but any implementation supporting version 1.x must also support version 1.y for each y < x. The F-bit indicates whether this is the last or only fragment of a message (zero) or whether further fragments will follow (one). The B-bit shows how the integers in this message (including the subsequent Message Length field) are encoded-zero means the integers are Big- Endian and one means Little-Endian. The Message Type field indicates what the message is for, using values from Table below. The Message Length gives the length of the remaining message, excluding the common header in bytes.

GIOP

Message Type	Message
0	Request. Sent by client (or server if bidirectional GIOP is in use) to invoke a COBRA object that is to read, write, or otherwise operate on an object. Request messages carry unique identifiers used to correlate replies and fragments.
1	Reply. Sent in response to a Request to return data that are read or to return the result of the operation in the request. A flag in the Request indicates whether a Response should be sent.
2	CancelRequest. Sent by the sender of a Request to attempt to cancel it before the receiver acts on it and sends a Reply.
3	LocateRequest. Sent to determine whether the receiver is capable of performing the requested operation on the specified object. The LocateReply can affirm or deny the request and can also redirect the request to another location. Note that these results are identical to the response to a Request message carried by a Reply, but that the LocateRequest does not carry the full data, which are useful if redirection is likely.
4	LocateReply. Sent in response to a LocateRequest.
5	CloseConnection. Sent by either end of a connection to indicate that the sender intends to close the connection and that any outstanding Request messages sent to it will not receive a Reply and will not be acted on.
6	MessageError. Reports a general, high-level parsing error such as an unsupported version number or an unknown message type. More detailed message-specific errors are handled in Reply messages.
7	Fragment. This message is used to continue and complete a sequence of fragments started by a Request or Reply that has the F-bit in the common header set to 1 to indicate that the data have been fragmented between multiple messages.

Each GIOP message starts with the common message header and continues with some message-specific fields, including a 4-byte request identifier to help correlate responses and fragments. The data are presented as a series of data values. On a Request message the data values are the input parameters to the object operation, and on a Reply they are the output parameters. Data values in a GIOP message can be represented by the BNF encoding shown below. Each value begins with an integer value tag to identify the data type. The value tag may optionally (according to the value of the value tag) be followed by strings giving a codebase universal resource locator (URL) and type information to help locate the data in a repository. Then comes the data (called the state). Alternatively, the value tag may be replaced by an indirection to the data, or a special tag to show that no data are present.

<value>::= 	<value_tag> [<codebase_URL>][<type_info>] <state> |
		<indirection_tag> <indirection> |
		<null_tag>

The state may be a sequence of one or more bytes (called octets) or may be a nested sequence of values, allowing data structures to be represented as shown in Figure below. Note that there is support for splitting large (that is, of many bytes) data values across messages by chunking them. The end tag is used to indicate the end of a series of data chunks or the end of a nesting of values.

<state>::= 	<octets>|
<value_chunk> [<end_tag>]|
<value> [<end_tag>]
<value_chunk>::= <chunk_size_tag><octets>
<octets>::= octet[<octets>]

Connections are initiated in GIOP by a client. It uses the transport mechanism to open a connection to the server. In early versions of GIOP only the client was able to send Request, LocateRequest, and CancelRequest messages, and only the server could send a CloseConnection message. In more recent versions the distinction between client and server is limited to connection establishment. The connection gives context to the request identifiers used in the messages and (obviously) transports the messages.

TCP/IP provides reliable connection-oriented transport and so should be suitable for use by GIOP, but TCP/IP is limited by the failure or closure of connections. In particular, TCP does not provide a graceful shutdown whereby data "in the pipe" are flushed before the connection is torn down. This is a requirement of GIOP because the server may send a CloseConnection message and then shut down the connection; if this operation is attempted in TCP, the CloseConnection message may be lost, leaving the client unsure whether a new invocation is required because the previous connection failed or whether the old connection was closed under the control of an application. To bridge this gap, an additional adaptation layer is added to GIOP to make the IIOP. Since IIOP is a minimum requirement of a conformant COBRA implementation, and since TCP/IP is almost ubiquitous, the term IIOP is used interchangeably with GIOP. IIOP is also defined by the OMG in the base COBRA specification along with GIOP.

The first requirement of IIOP is to extend the object profiles to contain the host on which the object is located and the port through which it can be accessed. The host is presented as a string that may contain a partially or fully specified host name (that is, a name such as "enterprise," or a fully qualified domain name for the host such as "enterprise.accounts.mycompany.com"), or the IP address of the host presented in dotted notation (e.g., "192.231.79.52"). The port number identifies the TCP port on which the server (that is, the identified host) will be listening.

IIOP modifies the procedure for closing a connection by stipulating that the receiver of a Close Connection message must close the connection. This takes the responsibility for connection closure away from the sender of the message and allows the process to complete successfully.