Tycho interfaces and hostname resolving issues.

This is in reply to Raz’s blog about a problem he was having with Tycho, the hypothesis was that Tycho was binding to the first network interface it found. This post out grew the comment box so it’s now here :)

I have checked what Tycho does - it binds to every interface on the port it wants, netstat output:

tcp 0 0 0.0.0.0:3535 0.0.0.0:* LISTEN 4671/java
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 4671/java

I also tested this on Holly (which is multi-homed) by running a Mediator and telnetting to it on all of the interfaces.

The problem you are having (and the code you are looking at) is to do with the URL the Mediator thinks you need to use to connect to it. When the Mediator starts it binds to two ports (either ones you tell it or ones it finds are free). Then to be helpful it tries to work out what URL could be used to connect to both of the ports.

So to work out a hostname to use for the WAN URL it uses this code:

InetAddress.getLocalHost().getHostName();

And to work out the IP to use in the LAN address is uses this:

InetAddress.getLocalHost().getHostAddress();


Now for producers and consumers this isn’t a show stopper because when you create a TychoConnector you can actually tell it what Mediator LAN URL to use and it doesn’t matter what the Mediator thinks (because it’s actually bound to every interface). So using this mechanism should let you talk to a Mediator regardless of what it detected when it started up.

The bugger is the WAN URL has to actually be right because other Mediators need to use it for communications. So what I think we should do is have an option that lets you tell the Mediator exactly what the WAN URL is. This also helps us out if you put the Mediator behind a HTTP proxy - which could mean the address used to talk to the Mediator over the WAN may be completely different the address used to contact the Mediator.

So I don’t think it’s the bug you think it is but highlights something I _should_ fix anyway.