Creation of wireless/wired links

[pictavien]

Hi,

I have build a test showing that checks the creation of links when wired and wireless links are mixed. In this test, the topology has only two nodes: src and tgt.

• The first test creates a wireless link by moving tgt into the communication range of src. Then a wired link is explicitly created between the nodes. Then tgt is moved away from src, out of the communication range.
• The second test creates links in the reverse order.

After each creation of a link I get the number of links using Topology.getLinks().
In the first case the sequence is : 1 2 2
In the second case the sequence is : 1 1 1
What is the expected behavior ?

[remikey]

I am not sure I understand what your tests actually do, but there seems to be something odd indeed.
Would there be a way for you to share your test code?

[pictavien]

You can find a new test for io.jbotsim.core on my branch wired-wireless-bug.

[remikey]

Your code looks correct. To me, it looks like a bug. But it needs to be confirmed by @acasteigts .

The issue seems to come from the way JBotSim implements wireless links update (in Topology.updateWirelessLink()).

In Node, we use a structure which does not currently allow the n1 Node to keep track of multiple outlinks to a specific n2 Node.
Yet, the Topology properly keeps track of both links.

[acasteigts]

@pictavien do you really mean 1 2 2 in the first case, or 1 2 1 ? If 1 2 2, for sure, there is a problem. If 1 2 1, I need to think this through and remember whether this is deliberate or not.

[pictavien]

Sorry for the late response. Yes I confirm the results.
What about the second case ? A wireless link is not created when a wired one already exists. Is it the expected behaviour ?

[acasteigts]

It is not impossible that at some point I decided that at most one link should exist between two vertices (and so if a wired link already exists, we do not supplement it with a wireless one). However, I think the expected behavior by a random user would be 1 2 1 in both cases. What do you think? If this is also what you think, I am OK to adopt this behavior.

[remikey]

I also think that a random user would expect the wired and wireless networks be handled separately.
As a user, I would like to be able to filter (by myself) the links going out of a Node by their type, without anything missing.

As a maintainer, the resulting code would probably be clearer (currently, things are handled differently in the Node and the Topology classes).

However, such a modification might impact performances and should be carefully planed.

[acasteigts]

I agree with @remikey, this matter should be carefully planed, and not only for performance. The current situation is the result of a duality between two aspects:

1. The will to limit the API to simple graphs: i.e. at most one link for a given neighbor (which explains that wireless links are not created when a wired link already exists)
2. The will to deal with wired and wireless links independently, allowing one of each type to co-exist

It is clear now that the 1.1.1 outcome for the second case was deliberate (due to point 1). Obviously, we must change the current situation, which is indeed inconsistent (thanks for spotting this @pictavien !), but we need a bit more time to choose well in which direction (1 or 2).