default tcp host

Havoc Pennington hp at
Thu Jun 14 07:05:03 PDT 2007


Daniel P. Berrange wrote:
> Actually it would - just report it as  '' or '::'  as appropriate
> for the protocol it ended up listening on. You can quite happily also
> call connect() on '' 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 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 I don't know) even while it reports 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.

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.


More information about the dbus mailing list