Browse Prior Art Database

METHOD TO DYNAMICALLY SWITCH TO THE OPTIMUM TRANSPORT PROTOCOL

IP.com Disclosure Number: IPCOM000014643D
Original Publication Date: 1999-Oct-01
Included in the Prior Art Database: 2003-Jun-20
Document File: 3 page(s) / 40K

Publishing Venue

IBM

Related People

Kent Hayes Jr: AUTHOR

Abstract

Disclosed is a method to enable software to switch to the optimum transport protocol as what is optimum changes over time. The transport is changed not only for software being newly started, but for any software currently using the required communication services. Consider the characteristics of 3 types of connections protocols. HTTP (Hypertext Transfer Protocol) Very Scaleable, Only uses server resource when the client and the server actually need to communicate. Can go through fire walls Can run over SSL for security Poor performer if there are large amounts of client server interactions RMI (Remote Method Invocation) High performance if there are large numbers of client/server interactions. Cannot go through fire walls

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 67% of the total text.

Page 1 of 3

  METHOD TO DYNAMICALLY SWITCH TO THE OPTIMUM TRANSPORT PROTOCOL

      Disclosed is a method to enable software to switch to the optimum transport protocol as what is optimum changes over time. The transport is changed not only for software being newly started, but for any software currently using the required communication services. Consider the characteristics of 3 types of connections protocols. HTTP (Hypertext Transfer Protocol) Very Scaleable, Only uses server resource when the client and the server actually need to communicate. Can go through fire walls Can run over SSL for security Poor performer if there are large amounts of client / server interactions RMI (Remote Method Invocation) High performance if there are large numbers of client/server interactions. Cannot go through fire walls

Ties up server and client resources

Local Function Call

Extreemly high performance

Only works is client and server are running in the same

namespace.

The optimum transport protocol for client/server interaction may

change over time both for new applications that are being run

and for software already running on the client machine. It may

also be different based on where the client software resides

in relation to the server software.

One example is Profile Management user preference functionality.

Profile Management enables client software to load and save

preferences on behalf of users. These preferences may also be

modified by Administrators.

In the general case, the clients using the Profile Management

preference API are communicating with the Server using HTTP. This

is optimal because under normal circumstances when a client runs

an application, it simply loads its configuration data

(1 client/server interaction). An application doing further

profile management interactions after this point is relatively

rare. Since there will be minimal ProfileManagement interaction

with the server after this point, there is no need to tie up

server resource by maintaining a connection to the server. This

makes the solution more scaleable. Additionally, this allows

clients to utilize ProfileManagement services through a fire wall.

1

Page 2 of 3

If the client launches a ProfileManagement Administration

application, there will likely be many ProfileManagement

client/server interactions. It would be beneficial to use a

persistent connection (i.e., RMI) for client/server interactions

at this point.

Once the Administration application has stopped, it is beneficial to return the use of HTTP for the reasons described above. If a client is actually a piece of code running in the same name space as the server side ProfileManagement code, it is by far more efficient to use a high performance local interface (i.e., direct function calls) for all software running in the same name space
(i.e., other Servlets or server side objects being accessed over a persistence connection like RMI or IIOP). The invention solves the problem by: Having either a class (call it ServletCommand...