| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
This is the place that needs the complete type definition. If it is
defined in reds.h, it can create circular references.
|
| |
|
|
|
|
|
|
|
| |
rhbz#994175
Start monitoring if the client connection is alive after completing
the bit-rate test.
|
|
|
|
| |
and completed
|
|
|
|
|
|
|
|
|
|
| |
This patch only employs setting the stream parameters based on
the initial given bit-rate, the latency, and the encoding size.
Later patches will also employ mjpeg_encoder response to client reports,
and its control over frame drops.
The patch also removes old stream bit rate calculations that weren't
used.
|
|
|
|
|
|
|
| |
Sometimes we want to send a notify to a single client, rather then to
all of them.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Currently main_channel_push_notify only gets passed a static string, but
chances are in the future it may get passed dynamically allocated strings,
prepare it for this.
While at it also make clear that its argument is a string, and simplify
things a bit by making use of this knowledge (pushing the strlen call down).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
| |
Also removed old migration leftovers.
|
|
|
|
|
|
|
|
|
| |
A channel pipe item type must start from PIPE_ITEM_TYPE_CHANNEL_BASE.
SPICE_MSG_MIGRATE value eq. PIPE_ITEM_TYPE_SET_ACK. Setting a pipe item
type to SPICE_MSG_MIGRATE, leads to red_channel handling PIPE_ITEM_TYPE_SET_ACK.
Also removed sending SPICE_MSG_MIGRATE. It will be handled in the next
patch.
|
|
|
|
|
|
| |
Tracking the channels that wait for migration data. If there
is a new migration process pending, when all the channels have
restored their state, we begin the new migration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sending SPICE_MSG_MAIN_MIGRATE_BEGIN_SEAMLESS and handling
SPICE_MSGC_MAIN_MIGRATE_CONNECTED_SEAMLESS
The src side signals the client to establish a connection
to the destination.
In seamless migration, the client is also used to perform
a sort of handshake with the destination, for verifying
if seamless migration can be supported.
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Allow sending tokens to a specific client.
- Do not ignore tokens that are sent from the client to the server.
The tokens support for multiple clients and for server side tokens
is still broken in reds. It will be fixed in following patches, when
the server-side agent code will use the SpiceCharDeviceState api.
Notice that ignoring the server-side tokens didn't introduce a problem
since both the client and the server set it to ~0.
|
|
|
|
|
|
|
|
|
| |
Add spice_server_set_name() and spice_server_set_uuid() that allows
the client to identify a Spice server (useful to associate settings
with a particular server)
The SPICE_MSG_MAIN_NAME and SPICE_MSG_MAIN_UUID messages are only sent
to capable clients, announcing SPICE_MAIN_CAP_NAME_AND_UUID.
|
|
|
|
|
|
|
|
|
|
| |
(1) not sending anything to a migrated client till we recieve SPICE_MSGC_MIGRATE_END
(2) start a new client migration (handle client_migrate_info) only after SPICE_MSGC_MIGRATE_END
from the previous migration was received for this client
(3) use the correct ticket
Note: we assume the same channles are linked before and ater migration. i.e.,
SPICE_MSGC_MAIN_ATTACH_CHANNELS is not sent from the clients.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the migration has completed successfully:
(1) send MSG_MAIN_MIGRATE_END to the clients that are connected to the target
(2) send MSG_MAIN_SWITCH_HOST to all the other clients
If the migration failed, send MSG_MAIN_MIGRATE_CANCEL to clients that are
connected to the target.
(cherry picked from commit 4b82580fc36228af13db4ac3c403753d6b5c40b5 branch 0.8;
Was modified to support multiple clients, and the separation of main_channel from reds)
Conflicts:
server/reds.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
migraton starts
(1) send SPICE_MSG_MAIN_MIGRATE_BEGIN upon spice_server_migrate_connect
(to all the clients that support it)
(2) wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) from all the relevant clients,
or a timeout, in order to complete client_migrate_info monitor command
(cherry picked from commit 5560c56ef05c74da5e0e0825dc1f134019593cad branch 0.8;
Was modified to support the separation of main channel from reds, and multiple clients)
Conflicts:
server/reds.c
|
|
|
|
|
|
|
| |
The code for setting and testing channel capabilities was
unnecessarily duplicated. Now it is in red_channel.
RedsChannel was dropped from Reds; It was used only for holding
the channels common capabilities, which are now held in RedChannel.
|
|
|
|
|
| |
instead of checking just for reds->main_channel check that there is at least
one client as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Merging the functionality of reds::channel, into RedChannel.
In addition, cleanup and fix disconnection code: before this patch,
red_dispatcher_disconnect_display_client
could have been called from the red_worker thread
(and it must be called only from the io thread).
RedChannel holds only connected channel clients. RedClient holds all the
channel clients that were created till it is destroyed
(and then it destroys them as well).
Note: snd_channel still doesn't use red_channel, however it
creates dummy channel and channel clients, in order to register itself
in reds.
server/red_channel.c: a channel is connected if it holds at least one channel client
Previously I changed RedChannel to hold only connected channel clients and
RedClient, to hold all the channel clients as long as it is not destroyed.
usbredir: multichannel has not been tested, it just compiles.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main channel deals with connecting new clients, announcing mouse mode
changes, and the agent channel. The implementation is currently done without
any changes to the protocol, so everything has to be either broadcast or
to a specific client.
channels list - specific client
mouse mode - broadcast
agent - broadcast
notify - broadcast (should have two modes, and use the appropriate)
Notable TODOs:
* migration testing
* agent tokens are wrongly sent (or did I fix that? check)
|
|
|
|
|
|
|
|
|
|
| |
Expose additional api to find a client given a connection_id. The connection_id
is first set when the first channel connects, which is the main channel.
It could also be kept in the RedClient instead, not sure.
TODO:
multiple todo's added for multiclient handling. I don't remember why
I wrote them exactly, and besides if I did any migration tests. So: TODO.
|
|
|
|
|
|
|
|
|
|
|
|
| |
They were globals before. This introduces api for other channels
to query the low bandwidth status. The queries themselves are still done
from the wrong context (channel and not channel client) but that's because
the decoupling of channel and channel client will be done in the following
patches.
Note that snd_worker.c got two copied function declarations that belong to
main_channel.h but can't be easily dragged into snd_worker.c since it still
uses it's own RedChannel struct.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That means RedClient tracks a ring of channels. Right now there will be only
a single client because of the disconnection mechanism - whenever a new
client comes we disconnect all existing clients. But this patch adds already
a ring of clients to reds.c (stored in RedServer).
There is a known problem handling many connections and disconnections at the
same time, trigerrable easily by the following script:
export NEW_DISPLAY=:3.0
Xephyr $NEW_DISPLAY -noreset &
for ((i = 0 ; i < 5; ++i)); do
for ((j = 0 ; j < 10; ++j)); do
DISPLAY=$NEW_DISPLAY c_win7x86_qxl_tests &
done
sleep 2;
done
I fixed a few of the problems resulting from this in the same patch. This
required already introducing a few other changes:
* make sure all removal of channels happens in the main thread, for that
two additional dispatcher calls are added to remove a specific channel
client (RED_WORKER_MESSAGE_CURSOR_DISCONNECT_CLIENT and
RED_WORKER_MESSAGE_DISPLAY_DISCONNECT_CLIENT).
* change some asserts in input channel.
* make main channel disconnect not recursive
* introduce disconnect call back to red_channel_create_parser
The remaining abort is from a double free in the main channel, still can't
find it (doesn't happen when running under valgrind - probably due to the
slowness resulting from that), but is easy to see when running under gdb.
|
|
|
|
| |
This makes it easier to introduce RedClient in the next patch.
|
|
|
|
|
|
|
| |
use MainChannel* instead of Channel* for a many functions in main_channel.h
(affects main_channel.c and reds.c).
some one liner fixes are hidden in here too.
|
|
|
|
|
| |
In C, the latter isn't a prototype for a function with no arg,
but declares a function with an undefined number of args.
|
|
|