{"action":"opened","issue":{"url":"https://api.github.com/repos/micropython/micropython-lib/issues/103","repository_url":"https://api.github.com/repos/micropython/micropython-lib","labels_url":"https://api.github.com/repos/micropython/micropython-lib/issues/103/labels{/name}","comments_url":"https://api.github.com/repos/micropython/micropython-lib/issues/103/comments","events_url":"https://api.github.com/repos/micropython/micropython-lib/issues/103/events","html_url":"https://github.com/micropython/micropython-lib/issues/103","id":177728545,"number":103,"title":"umqtt.simple socket behaviour when WiFi is degraded","user":{"login":"peterhinch","id":8437477,"avatar_url":"https://avatars.githubusercontent.com/u/8437477?v=3","gravatar_id":"","url":"https://api.github.com/users/peterhinch","html_url":"https://github.com/peterhinch","followers_url":"https://api.github.com/users/peterhinch/followers","following_url":"https://api.github.com/users/peterhinch/following{/other_user}","gists_url":"https://api.github.com/users/peterhinch/gists{/gist_id}","starred_url":"https://api.github.com/users/peterhinch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/peterhinch/subscriptions","organizations_url":"https://api.github.com/users/peterhinch/orgs","repos_url":"https://api.github.com/users/peterhinch/repos","events_url":"https://api.github.com/users/peterhinch/events{/privacy}","received_events_url":"https://api.github.com/users/peterhinch/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-19T08:28:33Z","updated_at":"2016-09-19T08:28:33Z","closed_at":null,"body":"umqtt.robust works when WiFi fails completely. In testing there are circumstances when WiFi performance can be degraded to a point where blocking sockets can hang indefinitely without throwing an OSError. The behaviour is hard to replicate consistently. Moving slowly to the limit of WiFi range can (rarely) provoke it. It occurs here every few hours even when well within range, perhaps owing to RF interference. I have seen the following in many hours of testing:\r\n\r\n1. Socket read and write methods hanging for long periods.\r\n2. Publish with qos==1 failing to receive a PUBACK.\r\n\r\nThese will cause an application to hang. Possible fixes:\r\n\r\n1. Use a socket timeout rather than a blocking socket.\r\n2. Implement a timeout in the qos==1 loop which waits for a PUBACK. This begs the question as to what to do if a PUBACK is not received when the timeout expires. Arguably the publication should be repeated with dup==1 on the grounds that the broker may not have received the original message.\r\n"}}
{"actor":{"display_login":"peterhinch"}}