{"action":"opened","issue":{"url":"https://api.github.com/repos/ncclient/ncclient/issues/159","repository_url":"https://api.github.com/repos/ncclient/ncclient","labels_url":"https://api.github.com/repos/ncclient/ncclient/issues/159/labels{/name}","comments_url":"https://api.github.com/repos/ncclient/ncclient/issues/159/comments","events_url":"https://api.github.com/repos/ncclient/ncclient/issues/159/events","html_url":"https://github.com/ncclient/ncclient/issues/159","id":179810771,"number":159,"title":"ssh data lost if writing faster than reading","user":{"login":"paulo-g","id":17781607,"avatar_url":"https://avatars.githubusercontent.com/u/17781607?v=3","gravatar_id":"","url":"https://api.github.com/users/paulo-g","html_url":"https://github.com/paulo-g","followers_url":"https://api.github.com/users/paulo-g/followers","following_url":"https://api.github.com/users/paulo-g/following{/other_user}","gists_url":"https://api.github.com/users/paulo-g/gists{/gist_id}","starred_url":"https://api.github.com/users/paulo-g/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/paulo-g/subscriptions","organizations_url":"https://api.github.com/users/paulo-g/orgs","repos_url":"https://api.github.com/users/paulo-g/repos","events_url":"https://api.github.com/users/paulo-g/events{/privacy}","received_events_url":"https://api.github.com/users/paulo-g/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-28T15:45:21Z","updated_at":"2016-09-28T15:45:21Z","closed_at":null,"body":"I've configured ncclient as a NETCONF notification subscriber, and was testing the reception of notifications, when I've noticed that sporadically notifications would be lost.\r\nAfter some analysis, the issue was tracked down to [ssh.py](https://github.com/ncclient/ncclient/blob/master/ncclient/transport/ssh.py), in particular in the _parse11 method, when completing a single NETCONF message:\r\n```\r\n                        self._dispatch_message(''.join(message_list))\r\n                        # reset\r\n                        rest = buf.read()\r\n                        buf = BytesIO()\r\n                        buf.write(rest)\r\n                        buf.seek(0)\r\n                        message_list = []\r\n                        self._message_list = message_list\r\n                        chunk_list = []\r\n                        expchunksize = chunksize = 0\r\n                        parsing_state11 = idle\r\n                        inendpos = parsing_pos11 = 0\r\n                        break\r\n```\r\n\r\nWhen reading from the buffer, if the data was written at a greater speed than read, it would result in finishing a NETCONF message, and having additional data waiting in the buffer. This was resulting in the 'rest' buffer. What I've seen is that the rest buffer was completely ignored afterwards, and not processed. By removing the break at the end of that code, the while cycle would continue, and the additional messages would be handled.\r\nHowever, in theory the buffer is being kept below (self_buffer = buf), but this is not working.\r\nGiven that I am not fully aware of the original design, I am not certain the removal of the break is the correct fix. At least I had no issues with normal communication after removing that. If this is confirmed to be the fix, I can provide a pull request with it.\r\n\r\nThis issue is only visible if a big amount of messages comes in the ssh connection, which is something typically only problematic if you have a big amount of async notifications arriving from the device. For normal RPC/RPC-reply communication, this is probably not an issue, which explains why nobody complained about it."}}
{"actor":{"display_login":"paulo-g"}}