| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
NET_TEST_WARMUP_BYTES is 0 so the warmup ping is the same as the one we
use to measure the latency. Even if it was not, the actual latency would
be the MIN() of both anyway so we might as well use both roundtrip times
to ward off latency jitter a bit.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
|
|
|
|
| |
error message.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
|
|
|
|
|
|
|
| |
rhbz#994175
Start monitoring if the client connection is alive after completing
the bit-rate test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes rhbz#918169
Some channels make direct calls to reds/main_channel routines. If
these routines try to read/write to the socket, and they get socket
error, main_channel_client_on_disconnect is called, and triggers
red_client_destroy. In order to prevent accessing expired references
to RedClient, RedChannelClient, or other objects (inside the original call, after
red_client_destroy has been called) I made the call to
red_client_destroy asynchronous with respect to main_channel_client_on_disconnect.
I added MAIN_DISPATCHER_CLIENT_DISCONNECT to main_dispatcher.
main_channel_client_on_disconnect pushes this msg to the dispatcher,
instead of calling directly to reds_client_disconnect.
The patch uses RedClient ref-count in order to handle a case where
reds_client_disconnect is called directly (e.g., when a new client connects while
another one is connected), while there is already CLIENT_DISCONNECT msg
pending in the main_dispatcher.
Examples:
(1) snd_worker.c
snd_disconnect_channel()
channel->cleanup() //snd_playback_cleanup
reds_enable_mm_timer()
.
.
main_channel_push_multi_media_time()...socket_error
.
.
red_client_destory()
.
.
snd_disconnect_channel()
channel->cleanup()
celt051_encoder_destroy()
celt051_encoder_destory() // double release
Note that this bug could have been solved by changing the order of
calls: e.g., channel->stream = NULL before calling cleanup, and
some other changes + reference counting. However, I found other
places in the code with similar problems, and I looked for a general
solution, at least till we redesign red_channel to handle reference
counting more consistently.
(2) inputs_channel.c
inputs_connect()
main_channel_client_push_notify()...socket_error
.
.
red_client_destory()
.
.
red_channel_client_create() // refers to client which is already destroyed
(3) reds.c
reds_handle_main_link()
main_channel_push_init() ...socket error
.
.
red_client_destory()
.
.
main_channel_client_start_net_test(mcc) // refers to mcc which is already destroyed
This can explain the assert in rhbz#964136, comment #1 (but not the hang that occurred before).
|
|
|
|
|
|
|
| |
If client_migrate_info was called once with cert-host-subject and
then again without cert-host-subject, on a third call to
client_migrate info, the cert-host-subject from the first call would
have been freed for the second time.
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
| |
If the server is a destination of seamless migration, send msgs to the client,
even though an init msg has not been sent to the client.
|
|
|
|
| |
The relevant flags reside in RedChannelClient and RedClient
|
|
|
|
| |
Also removed old migration leftovers.
|
|
|
|
|
| |
Also removed some unused definitions from reds that used to belong to
old agent and migration code.
|
|
|
|
|
|
|
|
|
| |
Before sending the above msg, if there is a pending partial msg that
has been read from the agent, we send it to the client. The alternative
was to keep the msg as part of the migration data, and then
to send it to the destination server via the client and to wait there
for the msg chunk completion, before sending it to the client. Of
course, the latter is less efficient.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
The relevant code is common to all channels.
The patch also contains a fix to the return value for
handle_migrate_data callback: s/uint64_t/int
|
|
|
|
|
|
|
|
|
|
| |
- handle SPICE_MSGC_MAIN_MIGRATE_DST_DO_SEAMLESS
- reply with SPICE_MSG_MAIN_MIGRATE_DST_SEAMLESS_ACK/NACK
- prepare the channels for migration according to the migration
type (semi/seamless)
see spice-protocol for more details:
commit 3838ad140a046c4ddf42fef58c9727ecfdc09f9f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Also Update server and client according to the change of
SpiceMsgMainMigrationBegin: it now holds all the fields inside
SpiceMigrationDstInfo.
|
|
|
|
| |
send SPICE_MSG_MAIN_AGENT_CONNECTED_TOKENS
|
|
|
|
|
| |
This is an intermediate patch. The next patch will actually
push the buffer to the device, instead of copying it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
| |
It will abort by default for critical level messages. That behaviour
can be tuned at runtime.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will replace the common/ directory with the spice-common
project. It is for now a simple project subdirectory shared with
spice-gtk, but the goal is to make it a proper library later on.
With this change, the spice-server build is broken. The following
commits fix the build, and have been seperated to ease the review.
v2
- moves all the generated marshallers to spice-common library
- don't attempt to fix windows VS build, which should somehow be
splitted with spice-common (or built from tarball only to avoid
generation tools/libs deps)
v3
- uses libspice-common-client
- fix a mutex.h inclusion reported by Alon
|
|
|
|
|
| |
qemu can call spice_server_set_name(s, NULL) when the name is not
given. Let's not crash in this case
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While git-bisecting another issue I ended up hitting and not recognizing
the bug fixed by commit 7a079b452b026d6ce38f95dcc397fa64b059fffb.
While fixing this (again) I noticed that (even after the fix) not all
users of ChannelCbs first zero it. So this patch ensures that all users of
ChannelCbs first zero it, and does the same for ClientCbs while at it.
Since before this patch there were multiple zero-ing styles, some using
memset and other using a zero initializer this patch also unifies all
the zero-ing to use a NULL initializer for the first element.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
..as a result of missing initialization of newly introduced
pre_disconnect in main channel.
|
|
|
|
|
|
|
|
| |
This is provided by <limits.h> on all platforms as long as _XOPEN_SOURCE
is defined. On Linux, this is 1024, on Solaris, this is 16, and on any
other platform, we now respect the value supported by the OS.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are all existing errors; fix them so they don't block future
commits in this file unnecessarily.
error (1): length @ server/main_channel.c +369
error (2): length @ server/main_channel.c +444
error (3): length @ server/main_channel.c +764
error (4): length @ server/main_channel.c +932
error (5): length @ server/main_channel.c +1044
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
|
|
|
|
| |
Remove any blank lines at the end of all source files
|
| |
|
|
|
|
| |
64 bit-ism removed.
|
| |
|
|
|
|
|
| |
printed before function name. No central location for prefixes.
Adding "WORKER", "ASYNC", "MAIN" since those were the current users.
|
|
|
|
|
|
|
|
|
|
| |
(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.
|
|
|
|
| |
by using the new SPICE_DEBUG_LEVEL.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|