Success: kde 3.1 cvs running on sgi IRIX!

Tim Jansen tim at tjansen.de
Mon Aug 12 12:27:49 BST 2002


On Monday 12 August 2002 04:06, Thiago Macieira wrote:
> The address used to communicate can only be discovered with certainty when
> the communication is already established, via getsockname(2) and
> getpeername(2). 

Yes, but this does not help me, because in many cases the connection is not 
established and in some cases I dont even know the IP of the other side. 

I need the IP for two things:
- to announce a service via SLP. SLP requires me to broadcast the URL of my 
service, so I need a IP of the system that is reachable in the local LAN
-to send invitation mails for Desktop Sharing. I need to include an 
internet-reachable IP of the system in the mail so the invited person knows 
to which system she must connect to

And there are other protocols which require the local IP as well, for example 
SIP.


> And in the light of all the NAT that is being done, trying
> to discover one's IP address locally doesn't help much. 

Yes, I am still hoping that a more mature version of TURN 
(http://www.jdrosen.net/midcom_turn.html) will be released soon. Right now 
the only way to get the public IP for TCP connections is UPnP's IGD spec, as 
used by Windows, but I really don't want to mess with UPnP stuff.


> As you said yourself in the comments, configuring the addresses using a
> KCM should be better.

On most systems the auto-discovery feature should work very well. The typical 
situation of a multi-homed system is one ethernet card and a PPP connection. 
In these cases it will take the PPP connection as "private" internet address 
and the ethernet address for LAN. You only need to configure manually when 
you have more than one ethernet card or PPP connection. 

The problem with KCM configuration is that the interfaces names are not 
stable. Configuring the IP address itself will fail in many cases (IP 
assigned by DHCP or PPP), and then you need to specify the interface name for 
the LAN and the "private" internet address. But as the name of the interface 
usually depends on the order they came up, this is not reliable. 

bye...





More information about the kde-core-devel mailing list