On Wed, Jan 14, 2009 at 01:36:16PM +0200, Igor Stasenko wrote:
2009/1/14 Andreas Raab andreas.raab@gmx.de:
Bert Freudenberg wrote:
On 14.01.2009, at 07:38, Andreas Raab wrote:
Hi Folks -
I have a quick question about the expected behavior of the Unix VM when running on a machine with multiple IP addresses. We have a box with two interfaces (eth0 and eth1 respectively) and only eth0 was originally enabled. Listening without specifying an interface worked fine for clients connecting to the (static) IP configured for eth0.
Then, we enabled eth1 and gave it its own (static) IP address. We had two images running, one without specifying the interface, one specifying the IP for eth1 (both images had been restarted after the change was made). The result was that clients could connect to the image running on eth1 but not to the one running on eth0. Only when we changed that image to use the explicit IP address configured for eth0 everything worked as expected (i.e., clients could connect to either IP address).
Question: Is this the expected behavior? I'm not sure if not specifying the interface implies that the VM accepts connections on all interfaces, or only the first one, the last one, a random one or not at all. Any insights are greatly appreciated - we have a working setup but it would be nice to know whether this is what we should expect to see or not.
by default, if you not specify interface (0.0.0.0) it should bind a socket on a loopback interface, and made visible to any public interfaces on the host (eth1, eth0 , whatever).
I'm not sure however how OS resolving a conflict, when one socket binds itself on default iface, while another one on specific one. It should either return an error saying that another socket already bound at same port, but if you using a murky option - SO_REUSEADDR, there could be variants :)
That sounds right to me also. If the two images both were attempting to listen on the same port number, and if they did not both explicitly specify different interfaces, then I would expect one and only one of the images to succeed.
Also, it looks like #primSocket:listenOn:backlogSize:interface: would fail silently, closing the listening socket but otherwise giving no indication of a problem.
Dave