How do osagents, clients, servers communicate (protocol/port #) with each other?

From Support
Jump to: navigation, search


Question:

Product: VBJ 3.x, VBC++ 3.x
Platform: NA
JDK: NA
Component: ORB runtime, osagent

How do osagents, clients, servers communicate (protocol/port #) with each other ?

Answer:

Communication between clients and servers



The clients and servers communicate TCP with each other using TCP/IP. When the server is started, if the BOA is initialized with the OAport property (OAport is the port number to be used by the object adapter when listening for a new connection).  This port is embedded in the server's Interoperable Object reference (IOR) and is used by the client to establish a connection to the server. If no OAport property  is specified, a TCP port is randomly picked for the server listener port.

Passing the OAport parameter as an argument to the object implementation's server process when it is started, can be done either programmatically or as a command line option.

(a) programmatically (VBJ example only):

// in server main() code
...
java.util. Properties props = new java.util.Properties();
props.put("OAport", "1234");
org.omg.CORBA.BOA boa = orb.BOA_init("TSession", props);
...

(b) Command line examples:

VBJ:

prompt> vbj -DOAport=1234 Server

VBC++:

prompt> Server -OAport 1234

Communication between osagents and its clients (other osagents, clients, servers)



The osagent uses UDP protocol to communicate with other osagents and also to communicate with the client and server program.

    Client    Osagent
               (Client/Server/Osagent)

Client logs in with osagent             --------------------------------> OSAGENT_PORT
Osagent confirms login  C1     <-------------------------------
Client requests send to osagent          --------------------------------> O1
Osagent sends replies to client C2     <-------------------------------
Osagent verifies if client is  alive C3     <-------------------------------
Client may respond             --------------------------------> O2

(a) The OSAGENT_PORT (default 14000) is the well-known port number, by which the client (client/server/other osagents) can initially establish contact with the osagent. Visibroker applications 'log in' to the osagent using this port.

(b) The osagent confirms login via a port number C1, dynamically assigned by client, during login.

(c) When the osagent is started, it dynamically allocates a  handler port O1, for all subsequent client requests to the osagent. Thus, for the life of that osagent, the port number used to send messages to the osagent is always the same. Starting with version 3.3 of the osagent, this port can be configured using the OSAGENT_CLIENT_HANDLER_UDP_PORT environment variable.  This environment variable is used only by the osagent, it is not used by VisiBroker applications.

(d) The client process also establishes a port C2 that the osagent uses to send replies to all the clients.

(e) The client also dynamically assigns a port number C3, to be used for requests originating from the osagent for verification (heartbeats).  Only rarely will the osagent actually verify if the client is up. Clients of the osagent send an "areYouAlive" message every two minutes. If the client has not sent an "areYouAlive"  for within an acceptable threshold the osagent will initiate active verification of the client. To verify, the osagent will dynamically allocate some port number O2 to receive a response. O1 always remains constant, while O2 changes with each request/response.

(f) The consequence is that a user must set explicit values for the OSAGENT_PORT and the OSAGENT_CLIENT_HANDLER_UDP_PORT in order to configure a firewall that sits between the application and the osagent.  It is not possible to set any of the other dynamically allocated ports (C1, C2, C3, O2). These dynamically allocated ports may make it impossible to successfully configure the osagent for use through some router/firewall configurations.  This is why it is often not advisable to use the osagent in such configurations.
 



Article originally contributed by Borland Developer Support