Re: Using remote method-calls over a tcp/ip network

[Kuang-Chun Cheng <kccheng openate com>]

Hi,

I decode your IOR string and get following:

-----------------------------------------------------------------------------------------------------------
Object ID: IDL:EzxS/Srvr:1.0
IOP_TAG_ORBIT_SPECIFIC: usock 
/tmp/orbit-pvanhoof/orb-2036448948343356007 IPv6 port 0
   object_key (24) '000000001013b87e5139df3e01000000ff2d996cf666a434'

IOP_TAG_INTERNET_IOP: GIOP 1.0 linux-2.maia-scientific.com:38663
   object_key (24) '000000001013b87e5139df3e01000000ff2d996cf666a434'
-----------------------------------------------------------------------------------------------------------

Maybe you should try to add

192.168.0.23 linux-2.maia-scientific.com  linux-2

to /etc/hosts at your client.


And if it's a network setup problem, you should get COMM_FAILURE
at the time you call CORBA_ORB_string_to_object().

At which point you got COMM_FAILURE ?

ORBit2 speak GIOP 1.2 instead of GIOP 1.0.   I don't konw if this might
be the problem ... don't have much experience about ORBit,  can't help
on that.


Regards,
Kuang-Chun Cheng
kccheng openate com




Philip Van Hoof wrote:

> On Fri, 2004-09-17 at 16:10 +0800, Kuang-Chun Cheng wrote:
>
>  
>
> > For COMM_FAILURE problem.  ORBit2 use hostname instead of IP
> > address to resolve server.  Make sure you can connect to your server
> > via hostname.
> >
> > I'm using ORBit2 myself and a lot of my customers have the same problem
> > when setup the ORBit2 client.   I think this issue should be put in FAQ. 
> >    
>
> This sounds like an issue that we needed to solve for ORBit-1 to ORBit-1
> tcp/ip connections. The question, however, remains in that case: howcome
> some methods do work and some specific methods don't during the same
> session?
>
> Is ORBit-2 using different resolving-techniques for different data
> structures?
>
> However, both client and server can resolve the hostname and ip-
> addresses correctly. To fix the issue above, we added this line at the
> serverside:
>
> 192.168.0.23    linux-2
>
> It makes the server resolve it's own hostname to his network ipadress in
> stead of localhost.
>
>
> At the server:
> [pvanhoof linux-2 Linux_Srvr]$ cat /etc/hosts
> 192.168.0.23    linux-2
> 127.0.0.1       localhost.localdomain   localhost
> [pvanhoof linux-2 Linux_Srvr]$
>
>
> At the client
> [freax lort eazyx]$ cat /etc/hosts
> 127.0.0.1       localhost.localdomain   lort    localhost
> # Maia
> 192.168.0.23    linux-2
> [freax lort eazyx]$
>
> Also note that the named for this network is also configured correctly
> [freax lort eazyx]$ cat /etc/resolv.conf
> ; generated by /sbin/dhclient-script
> search maia-scientific.com
> nameserver 192.168.0.2
> [freax lort eazyx]$ nslookup linux-2
> Server:         192.168.0.2
> Address:        192.168.0.2#53
>
> Name:   linux-2.maia-scientific.com
> Address: 192.168.0.23
>
> [freax lort eazyx]$
>
>
> This is the IOR-string (I can't make much out of it myself):
>
> IOR:010000001200000049444c3a457a78532f537276723a312e3000000002000000caaedfba54000000010100002c0000002f746d702f6f726269742d7076616e686f6f662f6f72622d32303336343438393438333433333536303037000000000018000000000000001013b87e5139df3e01000000ff2d996cf666a4340000000044000000010100001c0000006c696e75782d322e6d6169612d736369656e74696669632e636f6d000797000018000000000000001013b87e5139df3e01000000ff2d996cf666a434[
>
>
>
> Thanks for the fast response
>
>