Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sometimes receiving single zero byte #128

Open
dhalbert opened this issue Nov 16, 2022 · 2 comments
Open

Sometimes receiving single zero byte #128

dhalbert opened this issue Nov 16, 2022 · 2 comments
Labels
bug Something isn't working

Comments

@dhalbert
Copy link
Contributor

Why does #127 fix #126? As mentioned by @brentru in #127 (comment) and following

@jinglemansweep Hi - thanks for fixing this issue. @dhalbert - I do not think this is a network or a MQTT spec issue, b"\x00 is rx'd after the call to res = self._sock_exact_recv(1).

Considering some in #126 are having issues with non-native wifi, it's possible (don't know, guessing right now) that the issue is within this library's local implementation of _sock_exact_recv() vs the native impl. of _sock_exact_recv() (cc @calcut ☝️ )

        # CPython socket module contains a timeout attribute
        if hasattr(self._socket_pool, "timeout"):
            try:
                res = self._sock_exact_recv(1)
            except self._socket_pool.timeout:
                return None
        else:  # socketpool, esp32spi
            try:
                res = self._sock_exact_recv(1)

For now, though, I think this is an OK temporary change and will cause clients to poll faster until we resolve why the socket is rcv'ing a bytearray on some clients.

@flavio-fernandes
Copy link
Contributor

flavio-fernandes commented Nov 25, 2022

hi @dhalbert . Thank you for opening this issue!
A change in behavior I observe with recent MiniMQTT is that the client.loop() :


is now blocking until "something happened". In the past, calling it would return right away if there was no work for it to do.
In my experiments, my work around is to provide a small timeout parameter like this:

https://github.com/flavio-fernandes/pyportal_station/blob/53e54c29becb89dc946eede747f6a32022e7ec4a/code.py#L470-L471

What do you think? In my humble opinion, timeout=0 should remain the non-blocking API it used to be, so other things could also happen in the main loop of the circuit python application.

@brentru
Copy link
Member

brentru commented Apr 11, 2023

What do you think? In my humble opinion, timeout=0 should remain the non-blocking API it used to be, so other things could also happen in the main loop of the circuit python application.

I think so too, this is proposed within #142

@brentru brentru added the bug Something isn't working label Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants