Re: Finding an initial name-servive using multicasting
- From: Magnus Bergman <magnus bergman observer net>
- To: Ilguiz Latypov <ilatypov diskstream com>
- Cc: orbit-list <orbit-list gnome org>
- Subject: Re: Finding an initial name-servive using multicasting
- Date: Fri, 1 Apr 2005 14:16:40 +0200
> Some Linux distributions might not include the ORBit2 name server
> because Gnome applications register with a different server (OAF?
> Bonobo? Please correct me.)
>
> The name server is in the ORBit2 CVS repository along with the
> name resolution client.
I only install from source, and the name server program doesn't get
installed any longer. Perhaps it has to be explicitly enabled somehow?
>
> > > orbit-name-server-2 -ORBIIOPIPv4=1 -ORBIIOPIPSock=2809 \
> > > -ORBIIOPUNIX=0 -ORBCorbaloc=1 \
> > > --key=NameService
> >
> > This I probably don't understand since I can't see the use for it.
So I
> > just assume it's nothing that I need.
>
> The --key option allows clients to specify the ORBit2 name
> server's corbaloc with the shorter key. Without this option the
> own corbaloc generated by the ORBit2 name server contains a long
> hexadecimal name in the end.
Without knowing too much about it just sounds like an improvement to cut
some hexadecimal string of the end, shouldn't it always do that? But how
does this fit with the corba standard? Does it (at least theoretically)
work with mixed corba implementations?
> > Registering the IOR (or other identifier) of the corba name
> > service was exactly what I had in mind.
>
> To me, it was sufficient to register just the name server's host
> name and port number because other parts of the
> orbit-name-server-2 corbaloc are known in advance:
>
> corbaloc:iiop:1 2 HOSTNAME:PORT/NameService
Yes, I guess your right. But then again I'm concerned about the
standard. I guess it's always safe to assume that tcp is used (since the
lookup solutions discussed depend on it) and hence that iiop is used.
But the string "1.2" isn't that of some importance?
> > The only problem was that the length of the IOR exceeded the
> > maximum length of an mdns attribute. It could be solved with a
> > dirty hack or two, but I find it important to follow the mdns
> > standard too.
>
> With the above --key patch only the host name and the port number
> need to be registered with the multicast service.
Great. But I think that just using corbaloc instead is IOR was good
enough. It's possible that even the longer ones are short enough to used
as mdns attributes.
> > I just had a quick look at the SLP RFCs and it seems that mdns is a
> > little simpler, but otherwise the seem pretty much the same. Is
there
> > anything specific you wonder about mdns?
>
> I can only assume that mdns is mimicking DNS formats and
> protocols. In my case it was too complex as I needed only to
> resolve a certain service name into its host name and port number.
> I guess mdns gives more options and extensions based on the DNS
> protocol.
Howl that I'm using might not be a full implementation of mdns, but it
uses that standard. It's quite simple, you make a call to publish a
service there you specify the following:
* Human readable name of this particular service.
* IANA standard protocol name.
* Domain (if it's not just public).
* Host (if it's different from the one that makes the call).
* Port.
* Optional attributes.
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]