Searched hist:"57 b0cdf152b7266e68bfa3e84635d4bdb64ef2cd" (Results 1 – 2 of 2) sorted by relevance
| /qemu/include/io/ |
| H A D | channel-websock.h | 57b0cdf152b7266e68bfa3e84635d4bdb64ef2cd Mon Oct 09 14:34:06 UTC 2017 Daniel P. Berrange <berrange@redhat.com> io: simplify websocket ping reply handling
We must ensure we don't get flooded with ping replies if the outbound
channel is slow. Currently we do this by keeping the ping reply in a
separate temporary buffer and only writing it if the encoutput buffer
is completely empty. This is overly pessimistic, as it is reasonable
to add a ping reply to the encoutput buffer even if it has previous
data in it, as long as that previous data doesn't include a ping
reply.
To track this better, put the ping reply directly into the encoutput
buffer, and then record the size of encoutput at this time in
pong_remain. As we write encoutput to the underlying channel, we
can decrement the pong_remain counter. Once it hits zero, we can
accept further ping replies for transmission.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
|
| /qemu/io/ |
| H A D | channel-websock.c | 57b0cdf152b7266e68bfa3e84635d4bdb64ef2cd Mon Oct 09 14:34:06 UTC 2017 Daniel P. Berrange <berrange@redhat.com> io: simplify websocket ping reply handling
We must ensure we don't get flooded with ping replies if the outbound
channel is slow. Currently we do this by keeping the ping reply in a
separate temporary buffer and only writing it if the encoutput buffer
is completely empty. This is overly pessimistic, as it is reasonable
to add a ping reply to the encoutput buffer even if it has previous
data in it, as long as that previous data doesn't include a ping
reply.
To track this better, put the ping reply directly into the encoutput
buffer, and then record the size of encoutput at this time in
pong_remain. As we write encoutput to the underlying channel, we
can decrement the pong_remain counter. Once it hits zero, we can
accept further ping replies for transmission.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
|