Archived

This forum has been archived. Please start a new discussion on GitHub.

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

Comments

  • marc
    marc Florida
    It's on our todo list :)
  • I want to know which version will add this feather:)
  • marc
    marc Florida
    Most likely version 1.6. We need this feature also for improvements in Glacier, so that it can scale to more simultaneous clients. But I can't give you a date yet, sorry.
  • Hi Marc,
    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
  • marc
    marc Florida
    Thank you very much for the offer, but it is not necessary. We already started our implementation. It doesn't use the Context member in the Current. Instead, we store an additional TransportInfo member in Current. This is a smart pointer to a local object, which can then be down-cast to specializations, such as an SslTransportInfo object.
  • ok. I will wait for these to come in the new release. I am awaiting on this feature to finish the Ice Token Service (distributed mutex) service.
  • marc
    marc Florida
    I don't think you should use client endpoint information for a distributed mutex. Client connections can be opened and closed transparantly, or clients can open multiple connections to the same server. This also wouldn't work for UDP, or if you use a router such as Glacier.

    I believe a better solution would be to use UUIDs for "virtual mutexes" that you add to the context parameter.
  • i am currently restricting the distributed mutex to only connection oriented transmission type.
    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.
  • btw do you have the latency figures for the call to the UUID? Is it expensive?
  • marc
    marc Florida
    Originally posted by Harvinder
    i am currently restricting the distributed mutex to only connection oriented transmission type.
    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.
    Originally posted by Harvinder
    btw do you have the latency figures for the call to the UUID? Is it expensive?

    No, I don't have any measurements, but I believe it is negligible compared to the overall cost of a remote call.
  • Hmm, it makes sense to go the UUID way then.