We don't need a special "WebSocket" class, as websocket itself is just an
upgrade of an existing socket / connection, and trying to come up with a
concept where a Socket class magically upgrades to a WebSocket class would be
messy.
So let's have just a WebSocketHandler, that communicates over a StreamSocket
or SslStreamSocket, and be done with that :-)
Change-Id: I449e4d662fbe2c5b1789e308053e4a71376fe481
Introduce the appropriate interface instead of the template, so that we can
de-couple the ResponseClient from the Socket itself.
Change-Id: I21892bbce5d83a18ca580a25cfc2efbb05b08705
ConsoleCertificateHandler will block on stdin
when a certificate error occures. This is hardly
helpful to users. Although in a server environment
this is likely to go to the journal, we should
properly log it and shutdown, rather than hang
waiting for the unlikely console input.
Change-Id: I54bb38ec60f443c579ef20dbb759941fae182e5b
SSL's decryption frame is 16kb, so it
makes sense to read by that multiple
for efficiency reasons.
Change-Id: Ib5d7b5bfc18fa1b27bcbc9aac93350c4e1292874
Reviewed-on: https://gerrit.libreoffice.org/34451
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
We now always read new data, because
SSL might need to process internal buffers,
and call the app message handler as long
as it keeps consuming data.
Finally, we write when we have data
to flush, even if we didn't get POLLOUT
event, because SSL might need to do
handshake, which is handled by the write
handler.
Change-Id: I909333c3a0492b0830044d51ae478ac5981b1d90
Reviewed-on: https://gerrit.libreoffice.org/34448
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
We expect to have more data if the buffer was
filled completely. Otherwise, there is no
reason to suspect there is more data, unless
we hope to have received time in that short
interval, which is not very likely.
Change-Id: I9a3dcb6378e8dcfa0d49b6c7ea92d7cec6690787
Reviewed-on: https://gerrit.libreoffice.org/34446
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The new test sends data of of 1 byte to
N bytes and expects the exact same data
returned in response.
This tests both buffering sizes and
websocket frames.
Change-Id: Ic6232b4e899d82d90a0ee7c96e4852ffaaf8e958
Reviewed-on: https://gerrit.libreoffice.org/34441
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
SSL expects the write buffer to be the same on
retry. This requirement cannot be guaranteed
when using standard containers as the internal
memory might be re-allocated between calls.
Luckily SSL can relax this requirement when asked.
Change-Id: I26771609a8cc0f9de0e554f9fa255d998f6c7b14
Reviewed-on: https://gerrit.libreoffice.org/34440
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Draining the buffer is the correct appraoch
to avoid accumulating data in the kernel
unnecessarily. But it also reduces the overhead
of reparsing the incoming data for message
boundaries.
The client that is to parse the data should
parse as many messages as possible and remove
them from the socket buffer.
Finally, we probably need to cap the maximum
buffer size to avoid bloating. However this
heavily depends on the application's max
message size, assuming there is no separate
buffer beyond that of the socket to accumulate
the messages in.
Change-Id: I49c4eccebd474cd07ca84f3f4eae33bc717ed1f2
Reviewed-on: https://gerrit.libreoffice.org/34411
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Depending on the base class, which is passed as
template parameter, SimpleResponseClient can
abstract away the underlying socket type.
Change-Id: I59a403357512f329aa2565c1ef55094704e3b4ad
Reviewed-on: https://gerrit.libreoffice.org/34393
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
