<table><tr><td style="">giedrius created this revision.<br />giedrius added a project: KDE Connect.
</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>REVISION SUMMARY</strong><div><p>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 at 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.</p>

<p>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. Just that is done by my fix.</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>The scenario may be simulated with such bash script on peer side:</p>

<p>$ for i in $(seq 0 10); do echo $i > "tmp-$i.txt"; kdeconnect-cli --share "./tmp-$i.txt" --device 4b7309ec0a4ee3c1; done<br />
$ kdeconnect-cli --refresh</p></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>AFFECTED FILES</strong><div><div>src/org/kde/kdeconnect/Backends/LanBackend/LanLinkProvider.java</div></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>