<table><tr><td style="">giedrius edited the summary of this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-gqawutllpgt7um7/" rel="noreferrer">(Show Details)</a>
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D4788" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>CHANGES TO REVISION SUMMARY</strong><div><div style="white-space: pre-wrap; color: #74777D;">There is a problem, that if many network packets are sent in short time and also at the same time LanLink socket happens to be reset (calling LanLink.reset method), some packets may get lost. It seems that when LanLink is being reset and old socket is being closed, some data on the wire can be discarded - the peer then thinks that the packets were sent successfully, but the host happens to think that socket is closed <span style="padding: 0 2px; color: #333333; background: #f8cbcb;">at</span><span style="padding: 0 2px; color: #333333; background: #a6f3a6;">and</span> it is all over. As I am not Java programmer, I didn't find a way to close the socket in a manner that all the data would be fully transmitted. Not sure if it is possible with SslSocket class at all.<br />
<br />
On the other hand, it seems that LankLink reset shouldn't be needed at all if we already have a functional socket. As far as I know, socket resets may happen in two cases, when a peer connects directly to a previously announced TCP port or when a host connects to a peer TCP port in response to broadcast UDP datagrams. In the former case, we definitely cant ignore the new socket, because the peer might have a good reason to create a new connection - maybe the socket on its side is broken or smth. However on the later case, if the host already has a working socket, there is no indication that it is broken, hence no need to create new sockets and risk loosing packets. <span style="padding: 0 2px; color: #333333; background: #f8cbcb;">Just</span><span style="padding: 0 2px; color: #333333; background: #a6f3a6;">This fix does exactly</span> that <span style="padding: 0 2px; color: #333333; background: #f8cbcb;">is done by my fix. </span><span style="padding: 0 2px; color: #333333; background: #a6f3a6;">- prevents creating new sockets if there is one already.</span></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R225 KDE Connect - Android application</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D4788" rel="noreferrer">https://phabricator.kde.org/D4788</a></div></div><br /><div><strong>EMAIL PREFERENCES</strong><div><a href="https://phabricator.kde.org/settings/panel/emailpreferences/" rel="noreferrer">https://phabricator.kde.org/settings/panel/emailpreferences/</a></div></div><br /><div><strong>To: </strong>giedrius, KDE Connect<br /><strong>Cc: </strong>MayeulC, menasshock, apol, hkaelberer<br /></div>