default tcp host

Daniel P. Berrange dan at berrange.com
Thu Jun 14 02:04:14 PDT 2007


On Thu, Jun 14, 2007 at 10:05:03AM -0400, Havoc Pennington wrote:
> Hi,
> 
> Daniel P. Berrange wrote:
> >Actually it would - just report it as  '0.0.0.0' or '::'  as appropriate
> >for the protocol it ended up listening on. You can quite happily also
> >call connect() on '0.0.0.0' or '::' AFAICT - it'll just connect to anything
> >listening on that port.
> >
> 
> That will work on the local machine, but presumably connecting via TCP 
> to the local machine is basically a weird case. The normal thing with 
> TCP would be that there's some manual configuration of the host name, 
> like hp.corp.redhat.com or whatever, and then this host name should be 
> in the address the daemon reports for itself. I would think the daemon 
> should still bind to INADDR_ANY (or perhaps the list of addresses 
> reported for hp.corp.redhat.com? I don't know) even while it reports 
> host=hp.corp.redhat.com as the address to be used by clients. But maybe 
> it shouldn't.
> 
> For the normal session daemon case, the idea here is like setting a 
> local DISPLAY to be used for an app you're launching from a remote 
> xterm. So we do need to know in D-Bus a valid hostname usable by remote 
> apps. For that purpose the old code was probably good enough, even.

We could explicitly call gethostname() to retrieve the local hosts'
primary name & put that into the address in the INADDR_ANY scenario
which is basically what X does for DISPLAY env IIRC.

> Somewhat different: for what I am doing right now, I'm essentially 
> telling Avahi to advertise a D-Bus server on all interfaces on the 
> machine; Avahi figures out and tells the remote system the 
> hostname/address/port of each D-Bus server socket, so in this case the 
> D-Bus server itself does not really need to be able to report a valid 
> remote hostname. The D-Bus server itself does need to be able to listen 
> on all interfaces, though.
> 
> Another thing to keep in mind is that the server can report a _list_ of 
> addresses if it so desires, it need not report only one.

Yes, I saw those when adding multiple <listen> elements. Not sure it
directly helps with INADDR_ANY case, because there's no real hostname
associated with 0.0.0.0. While you could iterate over network interfaces
and reverse lookup the IP assigned to each, this isn't really correct
becaue IPs can come & go any time. So again AFAICT the best we can do
is use gethostbyname() to refer to the primary hostname.

Regards,
Dan.
-- 
|=-            GPG key: http://www.berrange.com/~dan/gpgkey.txt       -=|
|=-       Perl modules: http://search.cpan.org/~danberr/              -=|
|=-           Projects: http://freshmeat.net/~danielpb/               -=|
|=-   berrange at redhat.com  -  Daniel Berrange  -  dan at berrange.com    -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20070614/0621e9f7/attachment.pgp 


More information about the dbus mailing list