ICE extension suggestions....

Hello,

I have also been working on designing an O2O infrastructure and also attempt to address many shortcommings of CORBA.

Your protocol is much simpler and efficient than what I came up with. Though I am still hesitant about fixed endianess and forbidding method overloading. But you also have good reason to do so.

There are two major features I designed in my O2O system for which I don't see an equivalent in ICE.

On is the object referencing model and the other is security.

For the referencing model, Ice use a locator based on object naming. For an Internet wide application involving zillions of objects, I guess you would use composed naming as for the dns.

In my system a reference is a simple integer. Its the most compact, ensure uniqueness and location independency.

Named object access uses a specific directory service where an entry can hold the reference of an object or another directory with additional informations like a URL, icon, dates, ... Thus I make a clear functional separation between the locator service and the directory service.


For the security, when working over Internet, one needs to be able to authenticate the client and provide support for access control down to servant and method calls if possible. SSL support provided by Ice address only partially the security needs.

Beside, x509 certificats to be used with SSL have as CORBA quite a long list of undesirable features. A secured underlying O2O infrastructure could help to solve many problems of x509. (revocation checking, useless certificate info, renewal frequency of certificats and especially root CA certificates, ... )

My impression after reading the documentation (not in detail though) is that these functionalities could be added to Ice with very few extensions to the API. (backward compatible).

Comments

  • yonikyonik Member

    Your protocol is much simpler and efficient than what I came up with. Though I am still hesitant about fixed endianess and forbidding method overloading.
    Don't be hesitant about fixed endianess, it's definitely the way to go, esp considering many newer languages can't do a byte copy from a byte array straight into other types (ints or structs). Allowing both big and little endianess causes everyone to have to implement both and peppers your unmarshalling code with ifs that can potentially stall the processor pipeline. It's much cleaner (and often faster) just to pick one way and be done with it.

    Kudos on the string type too... picking UTF8 (and only UTF8) was really the best option IMHO. Compressing length fields into 1 byte (for lengths <255) is also a great idea.

    Integer types really could have been easily further compressed by allowing them to be variable length. One (among many) possible ways that isn't too complicated:

    bb=readByte()
    if (bb<247) intval=bb
    else intlen=bb-247; intval=readInt(intlen)

    It's not a big deal though... if one wanted to send large arrays of ints more efficiently, they could always marshal it themselves and stuff it in a byte array.
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    Re: ICE extension suggestions....
    Originally posted by ChMeessen
    Hello,

    I have also been working on designing an O2O infrastructure and also attempt to address many shortcommings of CORBA.

    Your protocol is much simpler and efficient than what I came up with. Though I am still hesitant about fixed endianess and forbidding method overloading. But you also have good reason to do so.

    The reason is simplicity. By always using little endian, we don't have to put information about byte order in protocol messages or into encapsulations. And operation overloading is a pain, because you would have to mangle the parameters types into the operation name. Also, there might be languages which do not support overloading. For these languges, names would then even have to be mangled at the language mapping level.
    Originally posted by ChMeessen
    There are two major features I designed in my O2O system for which I don't see an equivalent in ICE.

    On is the object referencing model and the other is security.

    For the referencing model, Ice use a locator based on object naming. For an Internet wide application involving zillions of objects, I guess you would use composed naming as for the dns.

    In my system a reference is a simple integer. Its the most compact, ensure uniqueness and location independency.

    Named object access uses a specific directory service where an entry can hold the reference of an object or another directory with additional informations like a URL, icon, dates, ... Thus I make a clear functional separation between the locator service and the directory service.

    I'm not sure I fully understand what you mean. If you only use integers for object identity, how can you ensure that the integer is globally unique?

    Also keep in mind that Ice has built-in identity: Given two proxies, you can determine if the two proxies refer to the same Ice object by comparing the identities locally. No remote check is required for this. Any scheme that would not include the object identity in proxies wouldn't allow us to compare identities locally and directly.
    Originally posted by ChMeessen

    For the security, when working over Internet, one needs to be able to authenticate the client and provide support for access control down to servant and method calls if possible. SSL support provided by Ice address only partially the security needs.

    Beside, x509 certificats to be used with SSL have as CORBA quite a long list of undesirable features. A secured underlying O2O infrastructure could help to solve many problems of x509. (revocation checking, useless certificate info, renewal frequency of certificats and especially root CA certificates, ... )

    My impression after reading the documentation (not in detail though) is that these functionalities could be added to Ice with very few extensions to the API. (backward compatible).

    I agree with you that SSL alone is very cumbersome for security. That's what we have Glacier for. With Glacier, you can basically install any kind of client authentication you like. The default is a simple user-id/password check with "crypt", but you can install other authenticiation mechanisms as well.
  • The integer id/idea is something I spent some time thinking about.

    I won't detail everything here until there is enough interest in the functionality.

    The integer is a big integer. Unique assignement is acchieved by assignment delegation. Each domain, computer and even process is assigned a range of assignable integer.

    When an object requires a new reference, it ask the adaptor for a new integer in his assigned range. As you see the operation is fast since it only requires to increment an integer. No network operations are required.

    This is equivalent to the IP address assignement model.

    Locating an object is mainly locating the adaptor. Using the ranges makes search fast, index compact and relocation easy. As for DNS, the locator is hierarchical. Root locator nodes may be replicated and distributed all over the world since there associated location information changes are very rare. This allows to support load, robustness, performance and to be DOS resistant.

    Note also that this abstract integer representation removes any constrains on the range granularity and sub tree depth.

    With dns naming, we are ending up with a very flat system because people want to use it as a directory service. (www.MyCompany.com). It is very likely that an object locator system using names would meet the same problem.

    There is much more to say about it, like the integer size and encoding and how object delocalisation is handled.


    It is true that object naming is a much more convivial solution. But if the main purpose is to provide a unique identifier, there is a waste of address space from the binary point of view.

    Acessing object by names is a functionnality that should be used only where it is really needed. It is only for a small fraction of objects in fact. For this one should use a directory service as previously described.

    Paul Vixie has written a very good article on this aspect and the missuse of the DNS and naming problem. Since I can't find its URL on internet anymore, I put it as attachement. Ignore the proposal though it is very similar to the integer reference. The analysis is very pertinent and still actual.

    There are some other internet ressources addressing the uniqueness issue in detail. Why it is needed and so.

    One major benefit of this architecture is that assignment is local and very fast. By use of caching mechanism, as with the DNS, object location can be also very fast. As with the DNS such a system can scale to very wide and very intensive usages.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Ice is actually pretty close to what you describe. Please read "20.4 Ice Locator Facility" in the latest Ice book for a description of indirect proxies.
    The object adapter namespace is flat though ... do you anticipate to use so many object adapters that a single IcePack database won't be enough?

    Ice also provides UUIDs to generate "cheaply" globally unique identities (see 10.7.4), but you can use any scheme for your application (e.g. the one you described) and save a little bit of bandwidth.

    Cheers,
    Bernard
  • The basic idea is to have one unique world wide object address space. Not just a local application addressing schema.

    This is equivalent to DNS and hosts.txt file. Hosts.txt is fine for small domain with a few machines. DNS is for a world wide object naming system.

    The reference system I partially described is a world wide object reference mechanism.

    No doubt that your Ice locator can do the same for small scale application. I am thinking of a different play ground scale.

    Do I need the justify the benefit for a world wide object address space with compact, unique and relocatable object references ?

    Look at SNMP, LDAP, HTTP,.... these can all be replaced by O2O protocols and benefit from the security and object referencing system.

    Consider new application like distributed phone books. You only need to keep references to the objects. The owner will update it. etc. There are million new usefull application.

    Have you question your self why CORBA is not so popular in the internet community ? Why are there so few public and large scale internet wide applications using it ?

    In my opinion there are two main reason for that. First object reference problem and second security problem. Third class transportability and fourth global garbage collector problem.

    Providing a new O2O protocol is not that difficult. Addressing these issues is a challenging task but could make a radical difference with the existing standard.
  • marcmarc FloridaAdministrators, ZeroC Staff Marc LaukienOrganization: ZeroC, Inc.Project: The Internet Communications Engine ZeroC Staff
    There is nothing in the locator mechanism that would prevent you from using a DNS-style hierarchy. In fact, it has been designed to work like this. IcePack simply doesn't implement a hierarchical system, but it would be possible to write an IcePack++, that does implement such a system, without any changes to the Ice core. What you would have to do, however, is to define a DNS-style object identity naming scheme.
  • Yes, that true. It would also be quite easy to implement.


    This solution is what I call composed name object identifier.

    The main disadventage is that it does not provide uniqueness property. This means that if one has a reference on object A with name "X", and object A is deleted. Nothing prevents the creation of an object B reusing the name "X".
    When the client will try to talk to A, it will in fact talk to B and this is a source of possible confusion.

    Another problem is that object references are not as compact as possible and have no upper size limit. It is much more convenient and efficient to manipulate a value with fixed size or for which one knows the maximum size. It is not a big deal for small scale applications.

    If one consider Internet scale applications, which should imply zillions of objects, then the reference size starts to matter. Consider an object reference as equivalent to a phone number. For embedded application where memory and cpu are still valuable resources this also matter. I guess you know the overhead of manipulating strings and the memory allocation requirements, etc. Fixed size object reference is not a feature, it is a requirement. (I learned this from my SNMP experience with OIDs).

    However on the other side, the advantages of composed names is that it is more convivial for humans, easier to debug and understand. But the the risk is that one confuse to types of functionalities locator and directory.

    For small scale applications it is ok, but for internet wide application, this might become a problem I think.
Sign In or Register to comment.