search

calimero-project / calimero-core

Core library for KNX network access and management
Other
126 stars 64 forks source link

Connection to KNX-Gateway established twice #85

Closed Maw-Jung closed 4 years ago

Maw-Jung commented 5 years ago

Hey! When connecting to a knx-gateway the constructor of KNXNetworkLinkIP (https://github.com/calimero-project/calimero-core/blob/7219703cc368f48c00ddddd18d59d286b94f7b27/src/tuwien/auto/calimero/link/KNXNetworkLinkIP.java#L229-L231) is connecting twice when using tunneling. The first link is the perma data link used for knx communication, the second is used for some setting requests and gets terminated shortly after. This leads me to my question, why this second one is neccessary, since the data link doesn't seem to wait for any of the information from the setting requests. The doubled connection leads to problems with specified tunnel connections at gateways or gateways only allowing one gateway. I'm happy to provide further informations and/or look forward for a short description of the mechanism to understand.

Greetings, Marcel

bmalinowsky commented 5 years ago

Read is blocking using responseFor, see https://github.com/calimero-project/calimero-core/blob/7219703cc368f48c00ddddd18d59d286b94f7b27/src/tuwien/auto/calimero/link/AbstractLink.java#L427

with line return responseFor... returning the response.

The warning in case the connection is not established is probably misleading because it is expected to fail with connection N+1, with N being the supported number of client connections (N=1 in your case).

I currently implemented it this way, because I cannot know the remaining usable server IAs in advance (without opening a local DM connection to check it, and that's racy anyway) and it's just simpler. The ideal sequence in case of 1 remaining connection would be to 1) open local DM for config, 2) close local DM, 3) try to open tunnel.

Maw-Jung commented 5 years ago

Thanks for the quick response, if i understood correctly the reading of the server settings i observed shall be blocking and in an ideal sequence finish before opening the tunnel. If this is how it currently works, i observed differently using wireshark, in which the packages for opening the tunnel are recieved first, then the connecting for the settings are seen and lastly the settings connection is closed, which in turn needs 2 connections to the gateway. If however the current way of implementation differs, my questions are answered. Thanks & Greetings, Marcel

bmalinowsky commented 5 years ago

No, you did observe correctly :)

Currently, the implementation opens the tunnel, then tries to configure it using a local DM connection (blocking, if there is a remaining connection slot), sets the config, closes local DM, and continues with the tunnel. (Therefore, requires an additional connection slot for a short time).

So, ideally, the sequence as described above is required in the case of only a single remaining connection. But as it is now, in case of an error the tunneling connection just goes forward using the default settings.