summaryrefslogtreecommitdiffstats
path: root/server/reds.c
Commit message (Collapse)AuthorAgeFilesLines
* server: Don't complain if setsockopt NODELAY fails on unix socketsHans de Goede2012-01-181-1/+3
| | | | | | | | | | | | With Daniel P. Berrange's patches to allow use of pre-supplied fd's as channels, we can no longer be sure that our connections are TCP sockets, so it makes no sense to complain if a TCP/IP specific setsockopt fails with an errno of ENOTSUP. Note that this extends Daniel's commit 492ddb5d1d595e2d12208f4602b18e4432f4e6b4 which already added the same check to server/inputs_channel.c Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* Allow auth to be skipped when attaching to pre-accepted clientsDaniel P. Berrange2012-01-091-8/+13
| | | | | | | | | | | When an applications passes in a pre-accepted socket for a client, they may well have already performed suitable authentication out of band. They should thus have the option to request that any spice authentication is skipped. * server/reds.c, spice.h: Add flag for skipping auth Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Add APIs for injecting a client connection socketDaniel P. Berrange2012-01-091-4/+25
| | | | | | | | | | | Allow applications to pass a pre-accepted client socket file descriptor in. The new APIs are spice_server_add_ssl_client and spice_server_add_client * server/reds.c: Implement new APIs * server/spice.h: Define new APIs Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Move SSL setup out of reds_accept_ssl_connectionDaniel P. Berrange2012-01-091-10/+21
| | | | | | | | | | | To allow setup of an SSL client, from a passed in client socket, move all the SSL client initialization code out of reds_accept_ssl_connection and into a new method called reds_init_client_ssl_connection * server/reds.c: Introduce reds_init_client_ssl_connection Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Rename __reds_accept_connection into reds_init_client_connectionDaniel P. Berrange2012-01-091-13/+18
| | | | | | | | | | | | Remove the accept() call from __reds_accept_connection and rename it to reds_init_client_connection. The caller is now responsible for accepting the new socket. The method reds_init_client_connection merely initializes it for usage. * server/reds.c: Add reds_init_client_connection Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* Merge reds_accept_connection into reds_acceptDaniel P. Berrange2012-01-091-18/+8
| | | | | | | | | | Neither reds_accept_connection or reds_accept are very long, so the split is pointless & increases code size for no gain. Merge them together to reduce code size * server/reds.c: Merge reds_accept_connection into reds_accept Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
* server: turn spice_server_migrate_start into a valid callYonit Halperin2011-11-021-7/+1
| | | | | | We will add a qemu call to spice_server_migrate_start when migration starts. For now, it does nothing, but we may need this notification in the future. (cherry picked from commit b8213167717979e6f2fb52646e43eb458634e6a1 branch 0.8)
* server: handling semi-seamless migration in the target sideYonit Halperin2011-11-021-37/+178
| | | | | | | | | | (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.
* server: move the linking of channels to a separate routineYonit Halperin2011-11-021-17/+28
|
* server: handle spice_server_migrate_endYonit Halperin2011-11-021-62/+42
| | | | | | | | | | | | | | | | 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
* server,proto: tell the clients to connect to the migration target before ↵Yonit Halperin2011-11-021-71/+58
| | | | | | | | | | | | | | | 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
* server: handle migration interface additionYonit Halperin2011-11-021-0/+29
| | | | | | | | (cherry picked from commit 3ac0075cdac8fa42de47a7882022795e96cb1fee branch 0.8) Conflicts: server/reds.h
* server/spice.h: semi-seamless migration interface, RHBZ #738266Yonit Halperin2011-11-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | semi-seamless migration details: migration source side --------------------- (1) spice_server_migrate_connect (*): tell client to link to the target side - send SPICE_MSG_MAIN_MIGRATE_BEGIN. This should be called upon client_migrate_info cmd. client_migrate_info is asynchronous. (2) Complete spice_server_migrate_connect only when the client has been connected to the target - wait for SPICE_MSGC_MAIN_MIGRATE_(CONNECTED|CONNECT_ERROR) or a timeout. (3) spice_server_migrate_end: tell client migration it can switch to the target - send SPICE_MSG_MAIN_MIGRATE_END. (4) client cleans up all data related to the connection to the source and switches to the target. It sends SPICE_MSGC_MAIN_MIGRATE_END. migration target side --------------------- (1) the server identifies itself as a migraiton target since the client is linked with (connection_id != 0) (2) server doesn't start the channels' logic (channel->link) till it receives SPICE_MSGC_MAIN_MIGRATE_END from the client. * After migration starts, the target qemu is blocked and cannot accept new spice client connections. Thus, we trigger the connection to the target upon client_migrate_info command. (cherry picked from commit 6e56bea67c5648b0c81990171d4bc0cf1a402043 branch 0.8) Conflicts: server/spice.h
* server: set & test channel capabilities in red_channelYonit Halperin2011-11-021-97/+52
| | | | | | | 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.
* [0.8 branch] server: add main_dispatcherAlon Levy2011-10-311-1/+3
| | | | | | | | | | | | | | | | | | | | | | | add main_dispatcher, a message passing mechanism for sending messages to the main thread. The main thread is the thread that implements SpiceCoreInterface, which is assumed to be a single thread. Similar to the async operation of red_worker, a socket pair is created and used to pass messages. The messages are a fixed size to ease parsing. A single message is defined to pass a channel_event. RHBZ: 746950 FDBZ: 41858 This patch is 0.8 branch only, for the master branch there should be a better approach to share code with red_dispatcher and ready the way for later adding more threads. cherry-pick from 0.8 80caf07e09efe14c67f89a3c01501a6a39681167 Conflicts: server/reds.c
* server: fix function prototypesChristophe Fergeau2011-09-051-23/+21
| | | | | | | | Several functions in server/ were not specifying an argument list, ie they were declared as void foo(); When compiling with -Wstrict-prototypes, this leads to: test_playback.c:93:5: erreur: function declaration isn’t a prototype [-Werror=strict-prototypes]
* Rename usbredir channel code to spicevmcHans de Goede2011-08-251-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While discussing various things with Alon in Vancouver, it came up that having a channel which simply passes through data coming out of a qemu chardev frontend unmodified, like the usbredir channel does, can be used for a lot of other cases too. To facilitate this the usbredir channel code will be turned into a generic spicevmc channel, which is just a passthrough to the client, from the spicevmc chardev. This patch renames usbredir.c to spicevmc.c and changes the prefix of all functions / structs to match. This should make clear that the code is not usbredir specific. Some examples of why having a generic spicevmc pass through is good: 1) We could add a monitor channel, allowing access to the qemu monitor from the spice client, since the monitor is a chardev frontend we could re-use the generic spicevmc channel server code, so all that is needed to add this (server side) would be reserving a new channel id for this. 2) We could allow users to come up with new channels of their own, without requiring qemu or server modification. The idea is to allow doing something like this on the qemu startup cmdline: -chardev spicevmc,name=generic,channelid=128 To ensure these new "generic" channels cannot conflict with newly added official types, they must start at the SPICE_CHANNEL_USER_DEFINED_START value (128). These new user defined channels could then either be used with a special modified client, with client plugins (if we add support for those), or by exporting them on the client side for use by an external ap, see below. 3) We could also add support to the client to make user-defined channels end in a unix socket / pipe, allowing handling of the data by an external app, we could for example have a new spice client cmdline argument like this: --custom-channel unixsocket=/tmp/mysocket,channelid=128 This would allow for something like: $random app on guest -> virtio-serial -> spicevmc chardev -> -> spicevmc channel -> unix socket -> $random app on client 4) On hind sight this could also have been used for the smartcard stuff, with a 1 channel / reader model, rather then the current multiplexing code where we've our own multiplexing protocol wrapper over the libcacard smartcard protocol. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/reds: reds_client_disconnect: remove wrong check for ↵Alon Levy2011-08-231-9/+5
| | | | | | | | reds_main_channel_connected The "channel->disconnecting" parameter already protects against recursion. Removed fixed TODOs.
* server/reds: fix reds_main_channel_connectedAlon Levy2011-08-231-1/+1
| | | | | instead of checking just for reds->main_channel check that there is at least one client as well.
* server: add public spice_server_get_num_clientsAlon Levy2011-08-231-0/+11
|
* server: registering RedChannel in reds, instead of ChannelYonit Halperin2011-08-231-60/+96
| | | | | | | | | | | | | | | | | | | | | | | 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.
* server/reds: add RedsState.allow_multiple_clientsAlon Levy2011-08-231-1/+12
| | | | | Currently set by environment variable SPICE_DEBUG_ALLOW_MC (any value means to allow multiple connections). Later will be set by spice api from qemu.
* server/main_channel: support multiple clientsAlon Levy2011-08-231-2/+4
| | | | | | | | | | | | | | | | 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)
* server/main_channel: move connection_id from redsAlon Levy2011-08-231-15/+18
| | | | | | | | | | 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.
* server/main_channel: move ping here from reds.Alon Levy2011-08-231-43/+0
| | | | | | | | | | | | | cleanup only. Note that the ping function is half used since the opt parameter stopped being called with anything but NULL, should be returned at some point, specifically when we drop the 250kbyte ping on start and do a continuous check for latency and bandwidth. See: 81945d897 - server: add new vd interface QTerm2Interface, Yaniv Kamay introducing the usage of ping with a non NULL opt 3f7ea8e7a - zap qterm interfaces, Gerd Hoffman removing it
* server/reds: add concept of secondary channelsAlon Levy2011-08-231-4/+26
| | | | | | | | | | | | | | | | | | Secondary channels are those that don't support multiple clients. The support added in this patch just doesn't let the second or more connected client receive the unsupported channels in the channels list sent by the server to the client. This doesn't handle the situation where: client A connects (gets all channels) client B connects (gets supported multiple client channels) client A disconnects (Suboptimal 1: B doesn't get new channels at this point) client C connects (Suboptimal 2: C doesn't get the full list of channels, but the partial one) Specifically the channels that only support a single client are: sound (both playback and record channels) smartcard tunnel
* server: Add RedClientAlon Levy2011-08-231-19/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* server/main_channel+reds: make main_channel_init return MainChannelClientAlon Levy2011-08-231-5/+6
| | | | This makes it easier to introduce RedClient in the next patch.
* server/main_channel: use MainChannel in sigAlon Levy2011-08-231-7/+14
| | | | | | | 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.
* server: Add a usbredir channelHans de Goede2011-08-101-0/+10
|
* server: Don't call vdagent chardev state callback on client (dis)connectHans de Goede2011-07-251-45/+20
| | | | | See this long mail for the rationale for this: http://lists.freedesktop.org/archives/spice-devel/2011-July/004837.html
* server: make sure we clear vdagent and update mouse mode on agent disconnectHans de Goede2011-07-211-1/+1
| | | | | | | | | | | | The check this patch removes causes us to not set vdagent to NULL, nor update the mouse mode when the guest agent disconnects when no client is attached. Which leads to a non working mouse, and on agent reconnect a "spice_server_char_device_add_interface: vdagent already attached" message instead of a successful re-add of the agent interface . hansg: Note this is commit 443994ba from the 0.8 branch, which I did not forward port back then because it seemed unnecessary on master, but it turns out that the (wrong) check was just hidden in another place on master.
* Fix spice-server/qemu channel version checksChristophe Fergeau2011-07-181-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When qemu creates a channel, reds.c contains code to check the minor/major channel versions known to QEMU (ie the ones that were current in spice-server when QEMU was compiled) and to compare these versions against the current ones the currently installed spice-server version. According to kraxel [1], the rules for these interface numbers are: "The purpose of the versions is exactly to avoid the need for a new soname. The rules are basically: (1) You add stuff to the interface, strictly append-only to not break binary compatibility. (2) You bump the minor version of the interface. (3) You check the minor version at runtime to figure whenever the added fields contain valid stuff or not. An example is here (core interface, minor goes from 2 to 3, new channel_event callback): http://cgit.freedesktop.org/spice/spice/commit/?id=97f33fa86aa6edd25111b173dc0d9599ac29f879 " The code currently refuses to create a channel if QEMU minor version is less than the current spice-server version. This does not correspond to the intended behaviour, this patch changes to fail is qemu was compiled with a spice-server that is *newer* than the one currently installed. This case is something we cannot support nicely. [1] http://lists.freedesktop.org/archives/spice-devel/2011-July/004440.html
* server: fix segfault if no migrate_info providedAlon Levy2011-07-061-0/+11
| | | | | | | qemu calls spice_server_migrate_switch even if it didn't do a spice_server_migrate_info first. Fix the resulting error by not pushing a switch host tag to the pipe in this case, and add a check anyway in the marshalling code just in case.
* server/smartcard: register channel only when hardware is availableAlon Levy2011-07-051-4/+0
|
* s/__visible__/SPICE_GNUC_VISIBLEChristophe Fergeau2011-06-221-43/+43
| | | | | The C specification reserves use of identifiers starting with __ to the compiler so we shouldn't use one such symbol.
* remove void * arithmeticChristophe Fergeau2011-05-031-1/+1
| | | | | | | With -Wpointer-arith, gcc complains about void pointer arithmetic. This is not a big deal with gcc, but could be with other compilers, so it's better to cast to char */uint8_t * before doing the arithmetic on such pointers.
* add missing staticChristophe Fergeau2011-05-031-8/+8
|
* add #include <config.h> to all source filesChristophe Fergeau2011-05-031-2/+3
| | | | | | | | When using config.h, it must be the very first include in all source files since it contains #define that may change the compilation process (eg libc structure layout changes when it's used to enable large file support on 32 bit x86 archs). This commit adds it at the beginning of all .c and .cpp files
* server: s/desable/disableChristophe Fergeau2011-05-021-1/+1
| | | | | This fixes a typo in some function names, there should be no functional change.
* use foo(void) instead of foo() in prototypesChristophe Fergeau2011-05-021-6/+6
| | | | | In C, the latter isn't a prototype for a function with no arg, but declares a function with an undefined number of args.
* server: make sure we clear vdagent and update mouse mode on agent disconnectHans de Goede2011-04-041-3/+0
| | | | | | | | The check this patch removes causes us to not set vdagent to NULL, nor update the mouse mode when the guest agent disconnects when no client is attached. Which leads to a non working mouse, and on agent reconnect a "spice_server_char_device_add_interface: vdagent already attached" message instead of a successful re-add of the agent interface .
* server: ignore SPICE_MSGC_MAIN_AGENT_START messages when there is no agentHans de Goede2011-04-041-0/+3
| | | | | This can happen for example when a SPICE_MSGC_MAIN_AGENT_START message from the client and the vdagent disconnecting race.
* server: hookup agent-msg-filter discard-all functionalityHans de Goede2011-04-041-30/+22
| | | | | | | This ensures that if the client or agent connects to the client-agent "tunnel" while the other side is halfway through sending a multi part message, the rest of the message gets discarded, and the connecting party starts getting data at the beginning of the next message.
* server: add discard all option to agent message filterHans de Goede2011-04-041-4/+5
|
* server: filter all data from clientHans de Goede2011-04-041-11/+11
| | | | | Filter all data from client, even when there is no agent connected to keep filter state correct.
* server: reset read/write filter on agent/client disconnectHans de Goede2011-04-041-0/+2
| | | | | | The agent message filter keeps track of messages as they are being send reset the relevant filter to its initial state when one of the 2 ends of the agent<->client "tunnel" disconnects.
* server: break read_from_vdi_port loop if the guest gets disconnectedHans de Goede2011-04-041-1/+1
| | | | | | | read_from_vdi_port calls dispatch_vdi_port data, which will disconnect the guest agent if it sends invalid data. It would then try to read more data from the disconnected guest agent resulting in a NULL ptr dereference, this patch fixes this.
* server: Don't stop writing agent data to the guest when the client disconnectsHans de Goede2011-04-041-2/+2
| | | | | | | | write_to_vdi_port() was checking for reds->agent_state.connected to determine wether it could write queued data. But agent_state.connected reflects if *both* ends are connected. If the client has disconnected, but the guest agent is still connected and some data is still pending (like a final clipboard release from the client), then this data should be written to the guest agent.
* server: Don't reset agent state when the client disconnectsHans de Goede2011-04-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We were calling reds_reset_vdp on client disconnect, which is not a good idea. reds_reset_vdp does 3 things: 1) It resets the state related to reading chunks from the spicevmc virtio port. If the client disconnects while the guest agent is in the middle of sending a chunk, this will lead to an inconsistent state, and lots of printing of "dispatch_vdi_port_data: invalid port" messages caused by this inconsistent state sometimes followed by a segfault. This can be triggered by copy and pasting something large (say a screenshot) from the guest to the spice-gtk client, as the spice-gtk client currently has a bug causing it to crash when receiving a multi chunk vdagent messages. Without this patch (and with the spice-gtk bug present) I can consistently reproduce this. 2) It clears any buffered writes from the client to the guest still pending because the virtio port cannot consume data fast enough. Since the agent itself is still running fine, throwing away writes for it because the client has disconnected makes no sense. Esp, since on clean exit the client may very well send a clipboard release message directly before closing the connection, and this may get lost this way. 3) It sets client_agent_started to false, this is the only thing which actually makes sense to do on client disconnect. Note that since we no longer reset the vdp state on client disconnect, we must now reset it on agent disconnect even if we don't have a client. So the reds_reset_vdp call in reds_agent_remove() gets moved to the top, above both the agent_state.connected and reds->peer checks which will both fail in the no client case.
generated by cgit (git 2.34.1) at 2024-06-13 15:20:47 +0000