summaryrefslogtreecommitdiffstats
path: root/server/reds.c
Commit message (Collapse)AuthorAgeFilesLines
* server: Add support for filtering out agent file-xfer msgs (rhbz#961848)Hans de Goede2013-06-061-4/+17
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Log actual address spice-server binds toChristophe Fergeau2013-05-191-5/+10
| | | | | | | | | | | It's not always obvious what address spice-server will bind to, in particular when the 'addr' parameter is omitted on QEMU commandline. The decision of what address to bind to is made in reds_init_socket with a call to getaddrinfo. Surprisingly, that function had a call to getnameinfo() already, but it does not seem to be using the result of that call in any way. This commit moves this call after the socket is successfully bound and add a log message to indicate which address it's bound to.
* reds: fix memory leak when core->base.minor_version < 3Yonit Halperin2013-05-081-3/+2
|
* reds: move handle_channel_event logic from main_dispatcher to redsYonit Halperin2013-05-081-5/+14
| | | | | main_dispactcher role is to pass events to the main thread. The logic that handles the event better not be inside main_dispatcher.
* reds: fix not sending the mm-time after migration when there is no audio ↵Yonit Halperin2013-05-011-4/+14
| | | | | | | | | | | | playback This bug results in the client dropping all the video frames after migration in case that (1) the hosts involved in migration have different mm-time; and that (2) there is no audio playback. This is relvant only for the client that was connected during the migration. rhbz#958276
* reds: support mm_time latency adjustmentsYonit Halperin2013-04-221-1/+27
| | | | | | | | When there is no audio playback, we set the mm_time in the client to be older than the one in the server by at least the requested latency (the delta is actually bigger, due to the network latency). When there is an audio playback, we adjust the mm_time in the client by adjusting the playback buffer using SPICE_MSG_PLAYBACK_LATENCY.
* inputs-channel: Handle printing of insecure keyboard notifyHans de Goede2013-03-151-5/+0
| | | | | | | | | This is clearly something which should be handled in the inputs_channel code, rather then having a special case for it in the generic channel handling code in reds.c. Moving it here also fixes the TODO we had on only sending this message to new clients. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* main-channel: Make main_channel_push_notify deal with dynamic memoryHans de Goede2013-03-151-2/+1
| | | | | | | | | | | 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>
* server/reds: Send the agent a CLIENT_DISCONNECTED msg on client disconnectHans de Goede2013-03-071-1/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | Client -> agent messages can spawn multiple VDIChunks. When this happens the agent re-assembles the chunks into a complete VDAgentMessage before processing it. The server only guarentees coherency at the chunk level, so it is not possible for a partial chunk to get delivered to the agent. But it is possible for some chunks of a VDAgentMessage to be delivered to the agent followed by a client to disconnect without the rest of the VDAgentMessage being delivered! This will leave the agent in a wrong state, and the first messages send to it by the next client to connect will get seen as the rest of the VDAgentMessage from the previous client. This patch sends the agent a new VD_AGENT_CLIENT_DISCONNECTED message from the VDP_SERVER_PORT, on which the agent can then reset its VDP_CLIENT_PORT state. Note that no capability check is done for this, since the capabilities are something negotiated between client and agent. The server will simply always send this message on client disconnect, relying on older agents discarding the message since it has an unknown type (which both the windows and linux agents already do). Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* reds: Use g_strlcpy instead of strncpyChristophe Fergeau2012-12-121-15/+17
| | | | | | | | | reds.c is using strncpy with a length one byte less than the destination buffer size, and is relying on the fact that the destination buffers are static global variables. Now that we depend on glib, we can use g_strlcpy instead, which avoids relying on such a subtle trick to get a nul-terminated string.
* Fail reds_init_socket when getaddrinfo failsChristophe Fergeau2012-12-121-0/+1
| | | | | | We currently output a warning when getaddrinfo fails, but then we go on trying to use the information it couldn't read. Make sure we bail out of reds_init_socket if getaddrinfo fails.
* Make sure strncpy'ed string are 0-terminatedChristophe Fergeau2012-12-121-2/+2
| | | | | | | | | | spice_server_set_ticket and spice_server_set_addr get (library) user-provided strings as arguments, and copy them to fixed-size buffers using strncpy. However, if these strings are too long, the copied string will not be 0-terminated, which will cause issues later. This commit copies one byte less than the size of the destination buffer. In both cases, this buffer is a static global variable, so its memory will be set to 0.
* server: add "port" channel supportMarc-André Lureau2012-12-051-1/+10
| | | | | | | | | | | | | | | | | A Spice port channel carry arbitrary data between the Spice client and the Spice server. It may be used to provide additional services on top of a Spice connection. For example, a channel can be associated with the qemu monitor for the client to interact with it, just like any qemu chardev. Or it may be used with various protocols, such as the Spice Controller. A port kind is identified simply by its fqdn, such as org.qemu.monitor, org.spice.spicy.test or org.ovirt.controller... The channel is based on Spicevmc which simply tunnels data between client and server, with a few additional messages. See the description of the channel protocol in spice-common history.
* agent: fix mishandling of agent data received from the client after agent ↵Yonit Halperin2012-11-301-6/+22
| | | | | | | | | | | | | | disconnection The server can receive from the client agent data even when the agent is disconnected. This can happen if the client sends the agent data before it receives the AGENT_DISCONNECTED msg. We should receive and handle such msgs, instead of disconnecting the client. This bug can also lead to a server crash if the agent gets reconnected fast enough, and it receives an agent data msg from the client before MSGC_AGENT_START. upstream bz#55726 rhbz#881980
* reds.c: fix calls to spice_marshaller_add_ref with ptr to memory that might ↵Yonit Halperin2012-11-261-10/+14
| | | | be released before sending
* Revert "server: add websockets support via libwebsockets"Alon Levy2012-11-041-52/+27
| | | | This reverts commit 63bb37276e028ab1b1c156c9e7907bf22b6d5952.
* server: add websockets support via libwebsocketsAlon Levy2012-10-251-27/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | New API: spice_server_set_ws_ports This adds an optional dependency on libwebsockets. You need to get my patched 0.0.3 version here: git://people.freedesktop.org/~alon/libwebsockets There is no qemu patches yet, to test change in reds.c the default value of spice_ws_port to 5959 (for the default of spice-html5). For testing there is an online client at http://spice-space.org/spice-html5/spice.html Known issues: 1. The tester (server/tests/test_display_no_ssl) gets into dropping all data after a few seconds, I think it's an issue with the implemented watches, but haven't figured it out. 2. libwebsocket's read interface is inverted to what our code expects, i.e. there is no libwebsocket_read, so there is an additional copy involved (see RedsWebSocket). This can be fixed. 3. Listening on a separate port. Since the headers are different, we could listen on the same port (first three bytes RED/GET). I don't know if we want to? Todos: 1. SSL not implemented yet. Needs some thought as to how. 2. Serve spice-html5 when accessed as a http server. Nice to have.
* server/reds.c: split off reds-private.hAlon Levy2012-10-251-176/+4
|
* reds: Report an error when reds_char_device_add_state failsChristophe Fergeau2012-09-201-0/+1
| | | | | | This used to abort with spice_error. The caller currently does not check spice_server_char_device_add_interface return value, but it's still cleaner to report an error in this case.
* reds: Check errors returned from SSL_CTX_set_cipher_listChristophe Fergeau2012-09-201-1/+3
|
* reds: Report errors from load_dh_paramsChristophe Fergeau2012-09-201-3/+10
|
* reds: Check reds_init_ssl errorsChristophe Fergeau2012-09-201-1/+3
| | | | | | Now that this function can fail, propagate any error up to the caller. This allows qemu to fail when an SSL initialization error occurred.
* reds: report SSL initialization errorsChristophe Fergeau2012-09-201-1/+7
| | | | | | | | | Errors occurring in reds_init_ssl used to be fatal through the use of spice_error, but this was downgraded to non-fatal spice_warning calls recently. This means we no longer error out when invalid SSL (certificates, ...) parameters are passed by the user. This commit changes reds_init_ssl return value from void to int so that errors can be reported to the caller.
* reds_init_net: report errors on watch setup failuresChristophe Fergeau2012-09-201-0/+3
| | | | | | | | | | We used to be aborting in such situations, but this was changed during the big spice_error/printerr cleanup. We are currently outputting a warning but not reporting the error with the caller when reds_init_net fails to register listening watches with the mainloop. As it's unlikely that things will work as expected in such cases, better to error out of the function instead of pretending everything is all right.
* reds: Abort on BN-new failuresChristophe Fergeau2012-09-201-1/+1
| | | | | | | BN_new returns NULL on allocation failures. Given that we abort on malloc allocation failures, we should also abort here. The current code will segfault when BN_new fails as it immediatly tries to use the NULL pointer.
* server: Filter VD_AGENT_MONITORS_CONFIGAlon Levy2012-09-131-1/+52
| | | | | | If the guest supports client monitors config we pass it the VDAgentMonitorsConfig message via the QXLInterface::client_monitors_config api instead of via the vdagent.
* server/reds: reuse already defined localAlon Levy2012-09-131-1/+1
|
* Implement spice_server_set_exit_on_disconnect to enable an option whereby ↵Jeremy White2012-09-051-0/+14
| | | | the spice server shuts down on client disconnect.
* char_device: don't connect a migrated client if the state of the device ↵Yonit Halperin2012-08-271-14/+30
| | | | | | | | might have changed since it was created If reading/writing from the device have occured before migration data has arrived, the migration data might no longer be relvant, and we disconnect the client.
* main: restore state from migration dataYonit Halperin2012-08-271-11/+151
| | | | Also removed old migration leftovers.
* main: send migration dataYonit Halperin2012-08-271-11/+91
| | | | | Also removed some unused definitions from reds that used to belong to old agent and migration code.
* main: send MSG_MIGRATE upon vm migration completionYonit Halperin2012-08-271-0/+44
| | | | | | | | | 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.
* reds: s/HADER/HEADERYonit Halperin2012-08-271-5/+5
|
* char device migration: don't read or write from/to the device while waiting ↵Yonit Halperin2012-08-271-6/+7
| | | | for migraion data
* replace some migration related spice_error calls with info/warningYonit Halperin2012-08-271-2/+2
|
* seamless migration: migration completion on the destination sideYonit Halperin2012-08-271-9/+33
| | | | | | 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.
* seamleass migration: manage post migration phase in the src sideYonit Halperin2012-08-271-13/+108
| | | | | | | | | | | In semi-seamless, SPICE_MSG_MAIN_MIGRATE_END is sent. In seamless, each channel migrates separately. The src waits till all the clients are disconnected (or a timeout), and then it notifies qemu that spice migration has completed. The patch doesn't include the per-channel logic for seamless migration (sending MSG_MIGRATE, MIGRATE_DATA, etc.).
* seamless migration: pre migration phase on the destination sideYonit Halperin2012-08-271-13/+62
| | | | | | | | | | - 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
* seamless migration: pre migration phase on the src sideYonit Halperin2012-08-271-2/+6
| | | | | | | | | | | | | | 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
* spice.h: add spice_server_set_seamless_migrationYonit Halperin2012-08-271-0/+9
| | | | | | | | | | This new call is used in order to identify whether qemu, or the management (e.g. libvirt), support seamless migration. If it is supported, qemu spice cmd-line configuration should have seamless-migration=on. In addition, we disable seamless migration support if multiple clients are allowed. Currently, only one client is supported.
* spice_server_vm_start/stop: notify red_dispatcher on vm start/stopYonit Halperin2012-08-271-0/+2
| | | | | | | Till now, red_worker was notfied about vm status changes via QXLWorker->start/stop (or spice_qxl_start/stop). Newer qemu, that supports calling spice_server_vm_start/stop, will call only these routines, and won't call QXLWorker->start/stop.
* spice.h: add entries for tracking vm stateYonit Halperin2012-08-271-1/+33
| | | | | | | | | When vm state changes (started/stopped), we notify all the attached SpiceCharDeviceStates about the change. This is mainly required for avoiding writing/reading to/from the device during the non-live stage of migration. spice version will be bumped in one of the following patches.
* reds: add tracking for char devicesYonit Halperin2012-08-271-0/+44
| | | | | | The list of attached char_devices will be used in the next patch for notifying each instance of SpiceCharDeviceState when the vm is started or stopped.
* agent: don't attempt to read from the device if it was releasedYonit Halperin2012-08-271-1/+3
| | | | | if vdi_port_read_buf_process failes, we detach the agent and also release the read buffer. We shouldn't try reading from the device afterwards.
* agent: reset client tokens when notifying on agent connectionYonit Halperin2012-08-271-6/+10
| | | | send SPICE_MSG_MAIN_AGENT_CONNECTED_TOKENS
* server/reds: more fixes for wrong spice_error in d2c99b59Alon Levy2012-07-221-68/+68
|
* server/reds: fix wrong spice_error in d2c99b59Alon Levy2012-07-111-26/+26
|
* server/reds.c: spice_printerr cleanupAlon Levy2012-07-051-148/+146
| | | | | | | | | | | | | | | | | | Rules for replacing spice_printerr: * if it's a client drop / agent drop, spice_error * if it's important, spice_warning * else, spice_info. The fourth rule is spice_debug if it's going to fill up the log, but nothing of the sort here. Other things this patch does: * changed reds_show_new_channel to reds_info_new_channel in an attempt to advertise it doesn't always show anything, unless SPICE_DEBUG_LOG_LEVEL >= SPICE_DEVUG_LOG_INFO (==3) * removes two lines of whitespace. * added "crashy" to multiple client warning (only warning introduced, the rest are errors).
* char_device: move SpiceCharDeviceState from the headerYonit Halperin2012-07-031-4/+4
| | | | In addition, I also removed the no longer used wakeup callback
* smartcard: use SpiceCharDeviceState for managing reading from the deviceYonit Halperin2012-07-031-1/+3
| | | | | | | This patch and the following one do not introduce tokening to the smartcard channel. But this can be done easily later, by setting the appropriate variables in SpiceCharDeviceState (after adding the appropriate protocol messages, and implementing this in the client side).
generated by cgit (git 2.34.1) at 2024-05-27 23:02:55 +0000