search

AtherEnergy / rumqtt

Pure rust mqtt cilent
The Unlicense
202 stars 71 forks source link

stream read timeout causes publish delays #24

Closed jrobsonchase closed 6 years ago

jrobsonchase commented 8 years ago

It appears that the call to connection.stream.set_read_timeout with the argument of 1 second is causing all publishes to only occur at the second boundary since the write call only happens after a TimedOut or a WouldBlock in the receive loop. It looks like the problem started in https://github.com/Ather-Energy/RuMqtt/commit/1fe12f46031b1c9ad7e9e02af37dd4dddcbfc152.

tekjar commented 8 years ago

@Pursuit92 That is an unfortunate drawback of the current design. Previously I was cloning TcpStream and using it across 2 different threads (one for n/w reads coz read call is blocking). This worked well for Non-TLS but once TLS came into picture, the design was wrong

https://github.com/sfackler/rust-openssl/issues/445 https://github.com/sfackler/rust-openssl/issues/325 https://github.com/sfackler/rust-openssl/issues/338

Good news is that I've plans to migrate this to use tokio-core (once there is a 0.2 release on crates.io coz mqtt requires recurring timeouts for pings) very soon and this wouldn't be a problem.

tekjar commented 8 years ago

Current write limit is hard coded to 1000 publishes/sec. I can add this to config but it wouldn't make any sense after migrating to tokio-core. I can finish this much faster if I get some help :)

jrobsonchase commented 8 years ago

I'd love to help, but I'm still working on getting my head around futures for my own purposes. I'll see if I can pitch in once I'm a bit more comfortable with them :smile:

tekjar commented 6 years ago

Should be fixed in tokio2 branch