Foolproof the SSDPReceiver timeout mechanism #27
Conversation
On OS X it is possible to have addresses that cannot receive packets but can send them so set a socket read timeout just to be safe.
|
Ah yes. It seems that this would also fix the issue of having For the AppVeyor build, it looks like |
| @@ -195,6 +200,11 @@ fn receive_packets<T>(recv: PacketReceiver, kill: Arc<AtomicBool>, send: Sender< | |||
| trace!("Waiting on packet at {}...", recv); | |||
| let (msg_bytes, addr) = match recv.recv_pckt() { | |||
| Ok((bytes, addr)) => (bytes, addr), | |||
| Err(ref err) if err.kind() == io::ErrorKind::WouldBlock => { | |||
There was a problem hiding this comment.
While testing on Windows I found that timeouts do not return WouldBlock but instead TimedOut. Is this behavior consistent on Mac OS as well?
There was a problem hiding this comment.
OS X and Linux return WouldBlock (see: https://is.gd/TFOY1G). There should probably be a rust issue for this.
I suppose for the moment the check should be for both.
There was a problem hiding this comment.
Looks like there was: rust-lang/rust#27773 (comment)
And in fact it's mentioned and documented: https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.html#method.set_read_timeout
|
Ah yes, I didn't think to check the docs first; I think their decision in the linked issue seems reasonable. Anyway, all is looking good, thanks for the pull request! Cheers! |
On OS X it is possible to have addresses that cannot receive packets but can send them so set a socket read timeout just to be safe.
I noticed this on tun devices with ipv6 link-local addresses. Previously the
receive_packetswould never time out.