Distribution layer: virtual IP addresses lead to interference

[GoogleCodeExporter]

On occasion I've noticed random disconnects between two local AmbientTalk VMs. 
These issues disappear when totally disconnecting from the LAN.

According to Dries the issue may be that in our test environment, we are also 
running VM's, who use virtual IP addresses.  When the MulticastListenerThread 
sees such an address and tries to connect to it, this fails, but it will block 
the thread's progress until the timout (~30s) occurs. In the meantime, however, 
heartbeats of live AmbientTalk VM's are left unprocessed, leading to 
disconnects with live AT VMs.

Possible fixes:
1) add a timeout in the connect() call in MulticastListenerThread:201
2) attempt connections to new VMs in a separate thread
3) check in processIncomingAddress whether the address is in the same subnet as 
the host adress
4) rework the IP probing strategy such that the AT VM only publishes itself 
under a publicly available address (a patch for that, coming from Dries & 
Kevin's NARs branch, is attached)

I suggest we go for 4) and test this solution.

Original issue reported on code.google.com by tvcut...@gmail.com on 30 May 2011 at 8:44

Attachments:

• net-probe.patch

[GoogleCodeExporter]

Come to think of it, students running AT on AirPROG receive an 192.168.6.x 
address, so we should also do #3.

Original comment by Botje.linux@gmail.com on 30 May 2011 at 12:11

[GoogleCodeExporter]

... and even then, a firewalled host could cause the connect() call to stall 
and timeout.

However, I do not think we should invest a lot of time in this, as it will be 
fairly obvious what is going on.

Original comment by Botje.linux@gmail.com on 31 May 2011 at 9:32