GNOME Bugzilla – Bug 792862
gpollableoutputstream: document side effects of WOULD_BLOCK on D/TLS
Last modified: 2018-01-31 22:37:56 UTC
If the underlying transport is D/TLS the same data and data length is required to be sent on the next iteration when a WOULD_BLOCK happens. This is due to the fact that gnutls or openssl keep an internal state for the data.
Created attachment 367365 [details] [review] gpollableoutputstream: document side effects of WOULD_BLOCK on D/TLS
Dan, I’m happy to accept this from the DTLS point of view, but would like your input from the ‘does this fit in with the intent behind GPollableOutputStream’ point of view. If not, it’s a bug in the DTLS implementation and I guess we’d need to cache the previous buffer+length when returning G_IO_ERROR_WOULD_BLOCK.
Review of attachment 367365 [details] [review]: .
Kind of a dup of bug 739983. (In reply to Philip Withnall from comment #2) > Dan, I’m happy to accept this from the DTLS point of view The problem exists with regular (non-D) TLS too, I think, it's just that everyone already does the right thing there, because with TCP-based protocols, you're generally going to want to transmit all of your data, so if you get back WOULD_BLOCK, you'll just retry without even thinking about it. As opposed to RTSP-over-DTLS, where maybe you'd rather drop the packet rather than retransmit it "late". > but would like > your input from the ‘does this fit in with the intent behind > GPollableOutputStream’ point of view. If not, it’s a bug in the DTLS > implementation and I guess we’d need to cache the previous buffer+length > when returning G_IO_ERROR_WOULD_BLOCK. It does not fit with the intent of GPollableOutputStream. However, note that you can't do anything in GTlsOutputStreamGnutls in this case (user tries to send X, gets WOULD_BLOCK, and then tries to send Y) except keep returning an error until the caller passes the correct data, which they presumably will never do. (You can't just silently attempt to resend the old data, since the new data may be predicated on the assumption that the old data wasn't sent, in some way.) Given that there's apparently a use case for *not* trying to resend the same data (at least with DTLS), it seems like this is a bug in gnutls for not letting you do that. (I assume the problem is that its internal encryption state, etc, are now in a state that assumes that it sent the old data, even though it didn't actually manage to send it yet. I don't know how hard it would be for them to change that.) So anyway, yeah, all glib can do right now is document this.
Review of attachment 367365 [details] [review]: OK, let’s push this then. Thanks for the analysis Dan.
Pushed to master. Attachment 367365 [details] pushed as 1a99154 - gpollableoutputstream: document side effects of WOULD_BLOCK on D/TLS