Archived

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

Newbie: How to search for Servers

Hello,

I just finished installing ICE and after some STLport problems with VS6, I am now using VS .NET. :) I am not yet through the documentation and prefer "learning by doing"...

I want to run one server, which offers different services. Therefore I create ObjectAdapters for every service, so I can manage them by different names. Now to the client side:
I am now looking for the easiest solution for the following problem:
When starting a client, it should search fo running servers offering the needed service (refered to by its name). The search domain is limited to a few IPs in the same domain, only differing by the last three ciphers. Perhaps there's a very easy solution, but i am not seeing it yet :confused:

Thanks for upcoming answers!

Comments

  • benoit
    benoit Rennes, France
    So you have several servers deployed on different machines and each server implements multiple services, correct? Why are you using different object adapters for each service implemented by the servers?

    I think the easiest to find these services would be to use the IceGrid registry. You can register each object (the objects implementing your services) with the icegridadmin tool 'object add' command or programatically with the IceGrid::Admin::addObjectWithType method. Then, your clients just need to connect to the IceGrid registry and use the IceGrid::Query interface to find these registered objects. I recommend you to check out the IceGrid chapeter in the Ice manual for more information, in particular the section 36.5 which discusses well-known objects.

    Let us know if you need more information!

    Cheers,
    Benoit.
  • Hi!

    I have the same use case sometimes. It would be a really cool feature to be able to seek a service within a certain sub-net automatically.

    Using the IceGrid Registry is just a semi-optimal approach because in consequence to the original question you have the follow-up question how to find the IceGrid Query service then. Or, the other way around: when I am able to place an IceGrid Registry into my network and now how to resolve it (using a .config file), I can also put the service that jaleira was speaking about into my network because I will then also be able to find it easily (using the same .config file).

    regs,

    Stephan
  • Rephrasing my question

    I think I was wrong in putting my question in words. So I rephrase my question!

    Actually I have one (or more) Hosts on which different Servers are running. Each Server offers (multiple) services, which are dynamically assigned and can change in different scenarios. So I was wrong in saying, that I want to create one ObjectAdapter vor each Service. What I wanted to do, was creating one ObjectAdapter vor each Server! My fault ;)

    On Client side I'd like to know which servers are available or rather which server offers my demanded service (perhaps more than one).

    I am not yet deep enough in this topic. What about using IceBox for my requirements?
  • IceBox is just a wrapper which allows to deploy and run your applications more easily. It has nothing to do with communication or service invocation, this is rather something which is part of IceGrid :)

    regs,

    Stephan
  • benoit
    benoit Rennes, France
    Yes, IceBox won't help you to discover services. As Stephan mentioned, it's just a container for IceBox services (see the Ice manual for details on IceBox services). As mentioned in my previous post, the easiest is probably to use the IceGrid registry and register your services as well-known objects. You can then easily lookup these objects with the IceGrid::Query interface.

    To answer Stephan's comments, yes, you'll need to configure the client to access the IceGrid::Query interface. However, it's quite easy to do :). You just have one property to set, the Ice.Default.Locator property. Usually, you'll use a hostname and fixed port for the locator proxy so you'll never need to change this configuration. Once it's configured, you can easily lookup other services without having to worry of their location on the network.

    We currently don't have any plans to allow searching for services on a given subnet without any configuration. I'm not sure this is something that really belongs to Ice actually, some systems already provide such a discovery mechanism (see www.zeroconf.org for example).

    Cheers,
    Benoit.
  • Hi again,

    sorry for kind of abusing this thread. It would be a real killer feature for Ice if one could do an automatic service query. Couldn't you think about implementing it. Unforunately, I cannot write about "commercial interests" concerning this feature but it could be the missing link and really ease Ice setup within networks. Imagine, I would just have to only have to say something like:

    type = IceGrid.QueryDisp_.ice_staticId();
    Ice.ObjectPrx prx = communicator().resolveObjectFromNetwork(type, "192.0.2.0", "255.255.255.0");

    and would retrieve an object of that particular type.

    regs,

    Stephan
  • My gut feeling is also that this is something that doesn't belong into Ice.
    For one, any such scheme would have to be implementable on a variety of different transports (TCP, UDP, SSL, with others maybe to come in the future). It's not obvious that all possible transports for Ice would be able to provide such a feature (which would require some form of broadcast/multicast capability at the network level).

    Also, it would be difficult to design this such that the client and server code remains free of transport-specific artifacts (such as IP addresses and subnet masks).

    Finally, there is also the issue of how such a mechanism could be made secure, in the sense that it must be possible to prevent bogus clients and servers from registering with the service. Further, malicious parties must be prevented from subverting the service, or form discovering sensitive information from observing the network traffic cause by such a service. (And, I'm afraid that we cannot put anything into Ice as a fundamental service unless it is possible to secure it.)

    Cheers,

    Michi.
  • Hi!

    I agree that it might be difficult to provide it as a part of the Ice framework because of the implementation complexity.

    I do not agree to the possibility of bogus clients. This problem already exists since it should mean no problem to pretend to be a certain service with a certain interface, listening on a certain port on a certain host. This is always a problem if you don't ship further data (keys) between communication parties. But anyway, that should not be the point to be discussed in this thread.

    Instead I want to suggest something that is similar to what Trolltech does. The have the core Qt distribution and for stuff which makes lots of use and which is not part of the 'core', they have a package called Qt solutions. Why not do something similar? Matthews current section about client interaction is something which would also make sense for such a solution package and service discovery could also make sense.

    One way to do this would be to discussn this issue in the Connections mag.

    And: would it really be that difficult? From the very top level (I didn't yet read the code). You already have the possibility to use UDP as the transport technology and UDP has a broadcasting feature. Wouldn't it be possible to combine it? And if offering a simple hook service on UDP which e.g. has features for authentication or other 'bogus detection' the service could then return further proxies which give access to the desired proxies....

    But this is just a basic idea.

    Best regards,

    Stephan
  • stephan wrote:
    I do not agree to the possibility of bogus clients. This problem already exists since it should mean no problem to pretend to be a certain service with a certain interface, listening on a certain port on a certain host. This is always a problem if you don't ship further data (keys) between communication parties.

    What I was alluding to here is that such a mechanism would necessarily involve UDP multicast or broadcast. But, as opposed to a connection-oriented transport, UDP is notoriously difficult to secure because all strong ciphers are stream ciphers that can't be applied to UDP because of the possibility of packets arriving out of order, getting duplicated, and getting dropped. So, the discovery mechanism would be difficult to secure, whereas ordinary Ice communication can be made secure by simply using SSL.
    Instead I want to suggest something that is similar to what Trolltech does. The have the core Qt distribution and for stuff which makes lots of use and which is not part of the 'core', they have a package called Qt solutions. Why not do something similar? Matthews current section about client interaction is something which would also make sense for such a solution package and service discovery could also make sense.

    Well, in a way, we already have that in form of the IceGrid registry. All that is needed is a single configuration item for clients to be able to access the registry.
    You already have the possibility to use UDP as the transport technology and UDP has a broadcasting feature. Wouldn't it be possible to combine it? And if offering a simple hook service on UDP which e.g. has features for authentication or other 'bogus detection' the service could then return further proxies which give access to the desired proxies....

    One problem I see is that the discovery mechanism would be tied to a specific transport, namely, UDP. That means that it can't be made available on different transports that don't provide UDP-like broadcast/multicast communications. However, Ice is meant to stay transport independent as much as possible, so it can be implemented with custom transports (which are often quite limited in their capabilities).

    Finally, past experience tells me that a discovery service based on UDP can be problematic. Specifically, Visibroker uses such a mechanism and I well remember the endless problems people had with it. In particular, recalcitrant routers refusing to forward packets caused endless grief for customers, and debugging the problems used to be hard in practice. Part of the problems may have been caused by incorrect design or implementation. (I don't really know for sure.) But this makes me at least wary of adding such a mechanism to Ice without a lot of further work and thought.

    Cheers,

    Michi.