Closed arnoutdekimo closed 8 months ago
Yes, I've wondered about capturing this and reporting it somehow, I will add it to the TODO list.
(FYI, my current workaround is using small socket timeouts (using my own big one externally) + uSockRegisterCallbackClosed
, and letting it set a boolean, so I can check after uSockRead
returns -1 whether the socket is still alive or not. )
Hi Arnout: I've pushed a preview branch of the change here https://github.com/u-blox/ubxlib/commit/4d29ef0f4a5195dc5f43b7a312582620952c2463. Is that the kind of change you were expecting? If so I'll push it to master
here (then delete the preview branch).
Hi, yup, sounds like what was missing, thanks!
The fix is now pushed to master
here in commit c315b4ffad17e6581185e9234cbe86263ce90275; I will delete the preview branch.
Hi,
Just a comment on the workings of the function uSockRead. If we set a read timeout of 10s
(uSockOptionSet(sock, U_SOCK_OPT_LEVEL_SOCK, U_SOCK_OPT_RCVTIMEO),
and poll uSockRead in a loop, we expected indeed after 10s of no data received, that the functions returns.However, if the socket is closed within that time, the module does report this:
But ubxlib does not use this information and keeps blocking for the timeout setting. (loop in
receive
function)Ideally, a posix socket would directly return in this case, indicating that the connection has closed.
It's possible to work around this behavior, but just letting it know that it is unexpected.