[omniORB] Message source

[Ivanov, Roumen]

Hi,
This might be suitable for you too.
Instead of the full servant interface you register a kind of factory in
which the clients register and obtain a servent IOR. See bellow:

interface Client
{
   ...
   ...
};

interface Servant
{
...
...
};

interface Server
{
    Servant    connect(Client client_obj, <more_attributes>);
};

The Server creates and activates one Servant per Client. The Servant
implementation will be initialized with, and keeps any needed data about the
Client and its session's specific parameters including the Client IOR.
The Server's implementation is extended with the real implementation of all
methods of the Servant, having an additional parameter like ServantImpl*.
(This will be of course invisible through the exposed interfaces).
The Servant implementation will redirect internally all calls to the Server
implementation, passing its own (C++) "this" in the additional parameter.
You will decide whether to increment the refCounter or not (to use an
instance of the refCounting object or pointer).

This model I implemented when I needed to migrate an old Orbix system to
OmniORB.
Orbix used to generate its stubs whith an additional last parameter
CORBA::Environment & (Orbix specific), through which you could obtain some
information about the caller (if not internal call).

Probably I'm not saying anything new and original, but it worked very well
for me, kept me away from TLS two years ago, and preserved the interfaces of
significant changes.

HTH,
Roumen


> -----Original Message-----
> From:	richard.hardgrave@teradyne.com [SMTP:richard.hardgrave@teradyne.com]
> Sent:	Friday, April 19, 2002 02:28
> To:	omniorb-list@uk.research.att.com; david.bellette@nec.com.au
> Subject:	Re: [omniORB] Message source
> 
> >>>>> Duncan Grisby writes:
> 
> >> On Friday 23 March, SaE wrote:
> >>> how to find out client IP on server side ?
> 
> >> You can't. The CORBA standard doesn't specify a way to do it, and
> >> omniORB doesn't have a proprietary extension for it.
> 
> If you just want to decide, based on the client IP address, whether to
> accept or decline a connection request from the client, you can use the
> gatekeeper interface inside omniORB. See the user guide for details.
> 
> On the otherhand, if your design requires you to determine the client IP
> address inside the implementation of an operation, you can use the
> gatekeeper interface to extract the client IP address from the socket
> (using getpeername()), put the info into a per-thread storage and
> extract
> the value in your implementation. You either use the pthread "key" or
> the
> equivalent in Win32 thread API to access the per-thread storage. With
> Win32, you must clean up the storage after use or there will be a memory
> leak.
> 
> (Credits to Sai-Lai Lo)
> 
> Regards,
> 
> Richard
> 
> > From owner-omniorb-list@uk.research.att.com Thu Apr 18 18:47 CDT 2002
> > From: "David Bellette" <david.bellette@nec.com.au>
> > 
> > Hi
> > 
> > If I have a servant with multiple client machines connected to the
> > servant, what is the correct way of telling which client made a
> > function call?
> > 
> > I can't see how this is done and the only way I can think of is
> > if I put some form of session id in in function call.
> > 
> > Surely, there is a better way. Any ideas welcome.
> > 
> > Thanks
> > 
> > David
> > 
> > 
> > 
> > 


If you have received this e-mail in error or wish to read our e-mail disclaimer 
statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ 
or contact the sender