Browse Prior Art Database

A smart way to reduce the payload in a Distributed ORB communication

IP.com Disclosure Number: IPCOM000199920D
Publication Date: 2010-Sep-21
Document File: 4 page(s) / 75K

Publishing Venue

The IP.com Prior Art Database

Abstract

In any Distributed Communication Mechanism like the ORB (Object Request Broker), marshalling/unmarshalling of data to and from the request/response messages is common. Marshalled data is preceded by an identifier called Repository ID (RepID). RepID consumes considerable amount of space in the message payload and becomes an overhead, the size of which depends on the classname of the object being marshalled. This document describes a system to reduce this overhead associated with RepID by replacing it with a unique number.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 39% of the total text.

Page 1 of 4

A smart way to reduce the payload in a Distributed ORB communication

A typical remote communications happens in the following way. To describe the invention in a better way let us consider the case of a ORB( Object Request Broker). However this invention is not limited to and ORB and can be extended for other distributed communication mechanism.

Server ORB
Hosts one or more remote objects


Accepts connections from the client ORB
Receives RMI/IIOP requests from the client ORB
Unmarshals (deserializes) the parameters available in the Request delegates the request to the servant
receives a response
marshals the return value into a response message
sends the response back to the client ORB

Client ORB
Opens a connection with the server ORB


Creates a RMI/IIOP request message
Marshals(Serializes) the parameters required to make the remote call into the request message sends the request to the server ORB
waits for the response from the server ORB
receives the response message
unmarshals the retunr value from the response message

Marshalling the parameters and values into the request/response messages requires that. each time a particular type of value is marshalled onto the stream it has to be preceded by a RepId (Repository Identifier). RepId is nothing but a Way of describing the class name. For e.g. if a value type

jav

RMI:

.lang.Long:205F6CCF002E6E90:3B8BE490CC8F23DF. This needs to be done every time the

object is marshalled onto the stream. If the same object is being marshalled multiple times in a message the CORBA specification provides a way by which offset indirection could be provided to a previous location where the similar object is marshalled. There currently exists no mechanism by which we could indirect to a repository Id marshalled across separate requests. The repository Id's happen to be consuming a significant amount of space in the message payload. longer the class names longer would be a repository Id for the Object being marshalled.

The problem being addressed here is to reduce the message payload by reducing the size of the repository Id's

The current disclosure tries to reduce the message payload using a unique number as a replacement Id for repository Id . However is not straightforward and simple as generating unique ids for each repository Id and use it. For the following mentioned reasons

The Specification does not have any provision for using smaller/replacement repository Ids. So it will

a

require restricting this method to runtime which are aware of the smaller versions of the repository Ids. There does not exist an algorithm which can create a unique long number for a given rep id


2.

String.Two or more strings could generate same number based on character sequence that occurs in the String.

In a distributed environment a Server may be communicating with multiple clients. Different entities

may wish to employ different methods to generate the unique number for a given repository Id. Moreover there should be a provisio...