[omniORB] ETS issues for upcoming 4.0 release

[jon.kristensen@kongsberg-simrad.com]

Duncan, others.

This reply was triggered by the fact that you now plan a release 4.0.1
within the next few days.

I still have not had time to test the omniORB snapshot with the
gethostbyname fix on ETS. Sorry about that.

I however took the time to do a quick test of inet_addr and gethostbyaddr
(the fix seems to use these) in a standalone program. Everything seems to
works fine in a pure windows environment, but it seems that gethostbyaddr
fails when trying to find any of my ETS machines, even when running under
windows XP. This is actually a different problem than the one I initially
reported, but more in line with my other observations. It seems that
gethostbyaddr actually uses some DNS functionality, and that it do not work
on, and cannot find machines that do not support these functions.

In my project I have a small set of machines with static  IP addresses.
Although the ETS kernel do support DNS, turning it on seems to add a fair
amount of overhead and delay that I do not want. For this reason I use
dotted decimal IP addresses rather than hostnames in my applications. The
problem is then that the IP addresses of my ETS machines are never
registered in any DNS server or DNS cache, and gethostbyaddr will fail on
any ETS or windows  machine given such an address. I suspect this to be a
problem on other embedded platforms as well.

This brings me back to my initial question. When you have a dotted decimal
address to begin with, is it then necessary to call any DNS functions at
all? In my private fix I fake a hostent struct using the dotted decimal
address string as the name and the value returned by inet_addr as the
address. I have never had any problems with that solution.

This is what I have done to get limcWrapper.cc working for me in all cases
(my added code marked within comments and some context added for clarity):

#ifdef __atmos__
  if ((hp = ::gethostbyname(name)) <= 0)
    {
      rc = 0;
      non_reentrant.unlock();
      return -1;
    }
#else
// Added 2002.10.04 by Jon Kristensen, Kongsberg Simrad AS
// According to VC60 documentation, gethostbyname() does not handle dotted
decimal strings
// It seems to work anyway in most cases, but not always and never under
the ETS kernel
#if defined(__WIN32__)
  struct hostent myhp;
  unsigned long addr = inet_addr(name);
  if (addr != INADDR_NONE)
    {
      // Fake a hostent structure based on our IP address
      static char * Aliases[1] = { NULL };
      static unsigned long * Adresses[2] = { &addr, NULL };

      hp = &myhp;
      hp->h_name      = (char*)name;
      hp->h_aliases   = (char**)Aliases;
      hp->h_addrtype  = PF_INET;
      hp->h_length    = 4;
      hp->h_addr_list = (char**)Adresses;
    }
  else
// End of added code
#endif
  if ((hp = ::gethostbyname(name)) == NULL)
    {

The code show above works on windows and on ETS. My initial post of this
fix had Aliases and Adresses declared as const, and that do not work in
release builds.

On unix (Solaris) we use the standard distribution. I do not know how
gethostbyname is implemented there, but it is able to locate our ETS
machines given a dotted decimal address.

Regards,
Jon Kristensen
--------------
Jon Kristensen
Principal Engineer, SW Embedded Systems
Kongsberg Simrad AS, Horten, Norway
phone:      +47 33 02 39 34
fax:  +47 33 04 76 19
email:      jon.kristensen@kongsberg-simrad.com






Duncan Grisby <duncan@grisby.org>@grisby.org on 06.11.2002 12:36:28
Internet mail from:

Sent by:    dpg1@grisby.org

To:    jon.kristensen@kongsberg-simrad.com
cc:    omniorb-list@omniorb-support.com

Subject:    Re: [omniORB] ETS issues for upcoming 4.0 release


On Tuesday 24 September, jon.kristensen@kongsberg-simrad.com wrote:

Sorry I didn't reply to this sooner. It got buried under lots of other
things, and I only just rediscovered it.

I recently checked in a fix for Win32 that doesn't use gethostbyname
for IP addresses. Can you see if that works for ETS?

> I have also added a zip file containing a small library (with VS 6.0
> source and project files) that needs to be linked in when using
> omniORB4.0 with ETS. This library implements the WSAIOctl function
> required which is not supported by ETS.

Is it OK to only include the source for this, rather than the binary
libraries?  If so, I'll put the files in the contrib directory. I want
to keep the number of binary things in the CVS repository to a
minimum.

Thanks, and sorry again that I ignored this for so long.

Duncan.

--
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
    -- http://www.grisby.org --