Availability of Client Endpoint information to the sever object implementation
Hi Folks,
Requirement: Provide way to get the client side context i.e. client side connection end point info to the server side object implementation.
For e.g. you would want to bind a uniq thread on the server side to clients accessing a particular object.
This has many application. For e.g to create services like distributed mutex/token service.
Why: To meet requirements on the server side where the client side context information is vital.
Solution: To provide this information to the client would impact the performance of each call as this would require getting this information and passing it to the object operation implementation. To avoid the penelty, slice can emmit this information into the generated code via a slice flag --emit-context. The emitted code would provide (1) this as a part of Ice::Current::endpoint <new member> string object or (2) provide this as a part of Ice::Current::Context with name value pair as Ice::Current::Context.first = "__ICE_ENDPOINTS__" and Ice::Current::Context.second = "local endpoint = 127.126.125.124:1234\nremote endpoint = 128.129.130.131:1234".
How: The IceInternal::Incomming:: has the _connection object. Call the _connection->toString to get this information. Use one of the above mentioned ways to pass it to the
Thanks
-
Best Regards,
Harvinder
Requirement: Provide way to get the client side context i.e. client side connection end point info to the server side object implementation.
For e.g. you would want to bind a uniq thread on the server side to clients accessing a particular object.
This has many application. For e.g to create services like distributed mutex/token service.
Why: To meet requirements on the server side where the client side context information is vital.
Solution: To provide this information to the client would impact the performance of each call as this would require getting this information and passing it to the object operation implementation. To avoid the penelty, slice can emmit this information into the generated code via a slice flag --emit-context. The emitted code would provide (1) this as a part of Ice::Current::endpoint <new member> string object or (2) provide this as a part of Ice::Current::Context with name value pair as Ice::Current::Context.first = "__ICE_ENDPOINTS__" and Ice::Current::Context.second = "local endpoint = 127.126.125.124:1234\nremote endpoint = 128.129.130.131:1234".
How: The IceInternal::Incomming:: has the _connection object. Call the _connection->toString to get this information. Use one of the above mentioned ways to pass it to the
Thanks
-
Best Regards,
Harvinder
0
Comments
I have completed the implementation of this feature. Can I submit the changes as a patch to you (diff of the v 1.5.1 with).
I have tested it on linux fedora2
Thanks
-
Best regards,
Harvinder
I believe a better solution would be to use UUIDs for "virtual mutexes" that you add to the context parameter.
I thought about having the UUID, but that would involve client to pass that information which makes the usecase of the mutex api's non intutive.
All that is required is to get the uniq handle to the client, and since connection endpoint information is already with the server, so I though of going the route of endpoints.
Well, if you do this, you are outside the Ice programming model. It can work, if you don't use any routers (like Glacier), and disable active connection management, and otherwise make sure that a client equals a connection. But it is risky, as changes in the Ice core might change the way how connections are handled.
No, I don't have any measurements, but I believe it is negligible compared to the overall cost of a remote call.