[omniORB] Any way to differentiate clients with omniORB

[Martin Trappel]

Hello.

Is there any way with omniORB to determine within a CORBA Function-Call
on the server side from which Client (e.g. IP-Address+Port) the call
originated? (Maybe something like the CoGetCallContext(..) function for
DCOM; although I'm not even sure that does the trick)

Our problem is that we have to adhere to a standardized CORBA interface
that does not incorporate multi-client functionality, but the customer
still needs (a simple setup for) multiple clients so I'm currently
searching for a workaround.

any pointers appreciated,
br,
Martin

[BaileyK at schneider.com ()]

I don't think there's anything simple. Possibilities include

1) Use a different servant, and thus a distinct CORBA object, for each
client.
2) If sharing servant state across clients is necessary, use a single
servant and register it multiple times with a POA with distinct object IDs.
Give each client a distinct IOR, and then the POA can tell you which IOR
was used to make the up-call.
3) Use an interceptor to store socket IP/port information in thread-local
storage and then access that within the up-call.

For #2 see
http://www.omniorb-support.com/omniwiki/OmniOrb4DevelopmentStatus#head-7b5cf379a284b2223858b197f61d632c0d35fd46

---
Kendall Bailey
Engineering & Research

Post by Martin Trappel
Hello.
Is there any way with omniORB to determine within a CORBA Function-Call
on the server side from which Client (e.g. IP-Address+Port) the call
originated? (Maybe something like the CoGetCallContext(..) function for
DCOM; although I'm not even sure that does the trick)
Our problem is that we have to adhere to a standardized CORBA interface
that does not incorporate multi-client functionality, but the customer
still needs (a simple setup for) multiple clients so I'm currently
searching for a workaround.
any pointers appreciated,
br,
Martin
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list

[Martin Trappel]

Post by BaileyK at schneider.com ()
I don't think there's anything simple. Possibilities include
1) Use a different servant, and thus a distinct CORBA object, for each
client.
2) If sharing servant state across clients is necessary, use a single
servant and register it multiple times with a POA with distinct object IDs.
Give each client a distinct IOR, and then the POA can tell you which IOR
was used to make the up-call.
3) Use an interceptor to store socket IP/port information in thread-local
storage and then access that within the up-call.
For #2 see
http://www.omniorb-support.com/omniwiki/OmniOrb4DevelopmentStatus#head-7b5cf379a284b2223858b197f61d632c0d35fd46

Thanks for these pointers!

Option 2 sounds quite promising ... would this conceptually create 2
CORBA Objects supported by one servant, or would it still be one CORBA
Object that only is registered twice? (What would _is_equivalent(..)
tell me?) Also, at the moment I'm just running the default POA with the
default policies (omni 4.1.2) ... I guess I'll have to do something
there too?

... anyways I'll follow your link and try it out from there ...

br,
Martin

[Wernke Zur Borg]

Post by Martin Trappel
Hello.
Is there any way with omniORB to determine within a CORBA
Function-Call
on the server side from which Client (e.g. IP-Address+Port) the call
originated? (Maybe something like the CoGetCallContext(..)
function for
DCOM; although I'm not even sure that does the trick)
Our problem is that we have to adhere to a standardized CORBA
interface
that does not incorporate multi-client functionality, but the
customer
still needs (a simple setup for) multiple clients so I'm currently
searching for a workaround.
any pointers appreciated,
br,
Martin

Hi Martin,

I had a similar problem where a single server needed to respond to
clients connecting on different interfaces. I would recommend you to use
interceptors, they are relatively easy to use. Limited but sufficient
support already exists in early OmniORB versions (4.0.x).

Cheers, Wernke

[BaileyK at schneider.com ()]

Yes, #2 would create multiple CORBA objects. Mapping them all to the same
servant can be done in a number of ways. You could use the
USE_DEFAULT_SERVANT request processing policy when creating a child POA.
Then have a factory object in the root poa which bootstraps the clients by
assigning a distinct ObjectID to each client and creating an object
reference using the child POA and ObjectID. The default servant can use
POACurrent to access the ObjectID. This is similar to the way a session
cookie works for a web browser.

You can also use a ServantLocator, and examine the ObjectID in the
preinvoke() call. I don't know which is more efficient.

It's been some time since I've used this stuff, so I may be wrong on some
details. If you don't have the Henning/Vinoski book, you should probably
get it.

There's all kinds of fun stuff you can do once you start to use child POAs,
servant managers, and ForwardRequests. I built a custom load
balancer/fail-over/implementation repository service with OmniOrbPy a few
years ago. It's been working flawlessly ever since.

---
Kendall Bailey
Engineering & Research

Post by Martin Trappel

Post by BaileyK at schneider.com ()
2) If sharing servant state across clients is necessary, use a single

Thanks for these pointers!
Option 2 sounds quite promising ... would this conceptually create 2
CORBA Objects supported by one servant, or would it still be one CORBA
Object that only is registered twice? (What would _is_equivalent(..)
tell me?) Also, at the moment I'm just running the default POA with the
default policies (omni 4.1.2) ... I guess I'll have to do something
there too?
... anyways I'll follow your link and try it out from there ...
br,
Martin

[Martin Trappel]

Post by BaileyK at schneider.com ()
Yes, #2 would create multiple CORBA objects. Mapping them all to the same
servant can be done in a number of ways. You could use the
USE_DEFAULT_SERVANT request processing policy when creating a child POA.
Then have a factory object in the root poa which bootstraps the clients by
assigning a distinct ObjectID to each client and creating an object
reference using the child POA and ObjectID. The default servant can use
POACurrent to access the ObjectID. This is similar to the way a session
cookie works for a web browser.
You can also use a ServantLocator, and examine the ObjectID in the
preinvoke() call. I don't know which is more efficient.
It's been some time since I've used this stuff, so I may be wrong on some
details. If you don't have the Henning/Vinoski book, you should probably
get it.
(...)

Thanks for the additional info!
(And, yes, I have the book. Would be quite lost otherwise :) )

I'll try to let you know what's come of it.

br,
Martin