summaryrefslogtreecommitdiffstats
path: root/server/red_channel.c
Commit message (Collapse)AuthorAgeFilesLines
* server: handling semi-seamless migration in the target sideYonit Halperin2011-11-021-1/+14
| | | | | | | | | | (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: set & test channel capabilities in red_channelYonit Halperin2011-11-021-11/+83
| | | | | | | 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.
* red_channel: Fix msg buf memleak on parser errorHans de Goede2011-08-251-0/+1
| | | | Signed-off-by: Hans de Goede <hdegoede@redhat.com>
* server/snd_worker.c: add red_channel_client_destroy_dummyAlon Levy2011-08-231-15/+21
|
* server/red_channel: release channel allocated message bufferAlon Levy2011-08-231-0/+1
| | | | | handler->cb->release_msg_buf was not being called except in the error path, causing a memory leak.
* server: registering RedChannel in reds, instead of ChannelYonit Halperin2011-08-231-140/+138
| | | | | | | | | | | | | | | | | | | | | | | 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/red_channel.c inroducing client_cbsYonit Halperin2011-08-231-2/+51
| | | | | client_cbs are supposed to be called from client context (reds). This patch will be used in future patches for relacing reds::Channel with RedChannel in order to eliminate redundancy.
* server/red_channel.c: pack all channel callbacks to ChannelCbsYonit Halperin2011-08-231-51/+32
|
* server/red_channel: introduce client ring in RedChannelAlon Levy2011-08-231-45/+193
| | | | | | | | | | | | | | | | | Also adds Drawable pipes and glz rings. main_channel and red_worker had several locations that still accessed rcc directly, so they had to be touched too, but the changes are minimal. Most changes are in red_channel: drop the single client reference in RedChannel and add a ring of channels. Things missing / not done right in red_worker: * StreamAgents are in DCC - right/wrong? * GlzDict is multiplied - multiple compressions. We still are missing: * remove the disconnect calls on new connections
* server/red_channel: add pipe_size helpersAlon Levy2011-08-231-0/+15
|
* server/red_worker: multiple client support - base splitAlon Levy2011-08-231-12/+0
| | | | | | | | | | | | | | | | | | This patch compiles but breaks spice. Split both display and cursor channels to a client part and channel part. Introduce DisplayChannelClient, CursorChannelClient, CommonChannelClient. don't disconnect channel on client disconnect. Move all caches to the ChannelClient's. Remove reference counting of the channel. No new functionality introduced. NOTE: Introduces a crash in disconnections, a regression, resulting from incorrect thread access, that is fixed in the patch titled: "server: registering RedChannel in reds, instead of Channel"
* server/red_tunnel_worker: trivial multi client supportAlon Levy2011-08-231-5/+0
| | | | | | | | | | | | s/TunnelChannel/TunnelChannelClient/ That's about it. this is probably the wrong way to do it. Not tested at all. What do we want, a separate interface per client? same interface for all clients? probably the later. This doesn't do that. Not tested, so probably doesn't even work. changes red_channel_pipe_item_is_linked to red_channel_client_pipe_item_is_linked, since tunnel channel is the only user, must be done in patch to not break compilation.
* server/red_channel: introduce pipes functionsAlon Levy2011-08-231-4/+55
| | | | | | | | | | Introduce functions to add (via producer method) the same item to multiple pipes, all for the same channel. Note: Right now there is only a single channel, but the next patches will do the per-channel breakdown to channel and channel_client before actually introducing a ring in RedChannel, this makes it easier to make smaller changes - the channel->rcc link will exist until removed in the ring introducing patch.
* server/red_channel: ignore error if already shutdownAlon Levy2011-08-231-0/+3
| | | | | | on red_channel_peer_on_incoming_error, if we are already shutdown, do not call the channel's error handler. Since the channel has been shutdown, we assume this is a second or later error, and handling has already occured.
* server/main_channel: move latency and bitrate to channel clientAlon Levy2011-08-231-0/+5
| | | | | | | | | | | | 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.
* server: Add RedClientAlon Levy2011-08-231-8/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/red_client: clear pipe on disconnectAlon Levy2011-08-231-1/+1
|
* server/red_channel: workaround for fast client disconnect bug (TODO - real fix)Alon Levy2011-08-231-0/+5
|
* server/main_channel: use MainChannel in sigAlon Levy2011-08-231-2/+2
| | | | | | | 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: move pipe from RedChannel to RedChannelClientAlon Levy2011-08-231-59/+90
| | | | | | | | | | | | | | | | | | | | | | | Another cleanup patch, no change to behavior (still one client, and it disconnects previous client if any). The implementation for multiple client is straightforward: the pipe remains per (channel,client) pair, so it needs to move from the RedChannel that to RedChannelClient. Implementation using a single pipe with multiple consumers (to reflect different latencies) doesn't fit well with pipe rewriting that is used by the display channel. Additionally this approach is much simpler to verify. Lastly it doesn't add considerable overhead (but see the display channel changes in a later patch for a real place to rethink). This patch is just technical, changing signatures to reflect the first argument (oop style) so red_channel becomes red_channel_client. Some places may seem odd but they should be fixed with later comits where the channels grow to support multiple clients. Sound (playback/record) channels are the only ones not touched - this is consistent with previous patches, since they have been left out of the RedChannel refactoring. That is left as future work. (note that they don't use a pipe, which was the reason for not refactoring).
* server/red_channel (all): introduce RedChannelClientAlon Levy2011-08-231-222/+405
| | | | | | | | | | | | | | | | | | | | | This commit adds a RedChannelClient that now owns the stream connection, but still doesn't own the pipe. There is only a single RCC per RC right now (and RC still means RedChannel, RedClient will be introduced later). All internal api changes are in server/red_channel.h, hence the need to update all channels. red_worker.c is affected the most because it makes use of direct access to some of RedChannel still. API changes: 1. red_channel_client_create added. rec_channel_create -> (red_channel_create, red_channel_client_create) 2. two way connection: rcc->channel, channel->rcc (later channel will hold a list, and there will be a RedClient to hold the list of channels per client) 3. seperation of channel disconnect and channel_client_disconnect TODO: usbredir added untested.
* server/red_channel: renames to use _proc postfix consistentlyAlon Levy2011-08-231-6/+6
| | | | | | | | | rename types - we use _proc suffix mostly to indicate function pointer types, use it for some function pointers that were missing it. s/channel_handle_migrate_flush_mark/channel_handle_migrate_flush_mark_proc/ s/channel_handle_migrate_data_get_serial/channel_handle_migrate_data_get_serial_proc/ s/channel_handle_migrate_data/channel_handle_migrate_data_proc/
* add missing staticChristophe Fergeau2011-05-031-5/+5
|
* add #include <config.h> to all source filesChristophe Fergeau2011-05-031-0/+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
* Revert "server/red_channel: red_channel_event: push on blocked"Marc-André Lureau2011-03-031-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 5062433d8af45822371b6487a8d7baea23071d18. red_channel_receive() can call red_channel_destroy() which frees channel. The condition bellow is then checked, which can access a freed channel: if (event & SPICE_WATCH_EVENT_WRITE || channel->send_data.blocked) Reverting this commit solves the issue without any apparent bugs/drawbacks, which kind of clears out the weird TODO. handle_dev_input: cursor connect ==11826== Invalid read of size 4 ==11826== at 0x4C6F83C: red_channel_event (red_channel.c:535) ==11826== by 0x41CB8C: main_loop_wait (vl.c:1365) ==11826== by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589) ==11826== by 0x41FE9A: main (vl.c:1411) ==11826== Address 0x31fb00f0 is 96 bytes inside a block of size 28,648 free'd ==11826== at 0x4A05372: free (vg_replace_malloc.c:366) ==11826== by 0x4C6F536: red_channel_destroy (red_channel.c:453) ==11826== by 0x4C52B5D: inputs_channel_on_incoming_error (inputs_channel.c:449) ==11826== by 0x4C6ED0E: red_channel_peer_on_incoming_error (red_channel.c:215) ==11826== by 0x4C6E731: red_peer_handle_incoming (red_channel.c:87) ==11826== by 0x4C6EA55: red_channel_receive (red_channel.c:154) ==11826== by 0x4C6F82D: red_channel_event (red_channel.c:530) ==11826== by 0x41CB8C: main_loop_wait (vl.c:1365) ==11826== by 0x437CDE: kvm_main_loop (qemu-kvm.c:1589) ==11826== by 0x41FE9A: main (vl.c:1411) ==11826== https://bugs.freedesktop.org/show_bug.cgi?id=34971
* server/red_channel: move out_bytes_counter from Outgoing to RedChannelAlon Levy2011-03-021-2/+10
|
* server/red_channel: split Incoming/Outgoing to callback and stateAlon Levy2011-03-021-31/+34
| | | | | | | | This allows later to have the callback table under RedChannel when the callbacks actually get used by RedChannelClient. Since the cb's are identical for different clients of the same channel it makes sense to store the callback pointers in one place per channel. The rest of the incoming and outgoing struct just gets moved to RedChannelClient.
* server/red_channel: no opaque in red_channel_peer_on_*_errorAlon Levy2011-03-021-8/+4
|
* server/red_channel: add red_channel_disconnect, use in red_workerAlon Levy2011-03-021-0/+9
| | | | replace channel_release_res in red_worker with red_channel_disconnect.
* server/red_channel: reset send_data.item to NULL after releaseAlon Levy2011-03-021-0/+1
|
* server/red_channel: add red_channel_{,no_}item_being_sentAlon Levy2011-03-021-2/+13
|
* server/red_channel: add red_channel_send_message_pendingAlon Levy2011-03-021-0/+5
|
* server/red_channel: add red_channel_all_blockedAlon Levy2011-03-021-0/+10
|
* server/red_channel (all): add red_channel_get_headerAlon Levy2011-03-021-0/+5
| | | | | This is useful during the channel specific channel_send_pipe_item_proc callback, it allows altering or reader the header being sent.
* server/red_channel: add red_channel_get_first_socketAlon Levy2011-03-021-0/+8
| | | | | | Use in main_channel. This is just for backward portability later when multiple clients are introduced - needs to be considered (which sockets do we want to export from libspiceserver?)
* server/red_channel (+): remove red_channel_add_bufAlon Levy2011-03-021-6/+1
|
* server/red_channel (all): add red_channel_get_streamAlon Levy2011-03-021-0/+6
| | | | | use in config_socket, this makes the stream internal to the RedChannel implementation that will change later for multiple client support.
* server/red_channel (all): handle MIGRATE_DATA and MIGRATE_FLUSH_DATAAlon Levy2011-03-021-3/+37
| | | | | | | | | | Handling done in red_channel instead of per channel, using call backs for the channel specific part. Intended to reduce furthur reliance of channels on RedChannel struct. The commit makes the code harder to understand because of the artificial get_serial stuff, should later be fixed by having a joint migration header with the serial (since all channels pass it).
* server/red_channel (all): add red_channel_get_marshallerAlon Levy2011-03-021-0/+4
| | | | | | | For ussage in the send_item callback. It's only valid during this time anyway (should make it return NULL in other occasions?) No more direct usage of RedChannel.send_data.marshaller by channels.
* server/red_channel: move SET_ACK to red_channelAlon Levy2011-03-021-0/+27
|
* server/red_channel: add more ack apiAlon Levy2011-03-021-0/+10
|
* server/red_channel (all): makes red_channel_reset_send_data privateAlon Levy2011-03-021-16/+33
| | | | ready the way for handling ack messages in RedChannel.
* server/red_channe: make hold_item take a channel argAlon Levy2011-03-021-1/+1
|
* server: rename s/peer/streamMarc-André Lureau2011-02-281-24/+24
| | | | | | | | This is stylish change again. We are talking about a RedStream object, so let's just name the variable "stream" everywhere, to avoid confusion with a non existent RedPeer object. https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: use the new reds_stream_{read,write}Marc-André Lureau2011-02-281-3/+7
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: use reds_{link,stream}_free()Marc-André Lureau2011-02-271-2/+1
| | | | | | Be carefull removing the watch before, like __release_link https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: add reds_stream_{read,write,free,remove_watch}()Marc-André Lureau2011-02-271-1/+1
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server: s/RedsStreamContext/RedsStreamMarc-André Lureau2011-02-271-5/+5
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server/red_channel: style fix in red_channel_init_send_dataAlon Levy2011-02-071-2/+2
|
* server/red_channel: red_channel_pipe_clear: assert on NULL channelAlon Levy2011-02-071-1/+2
|
generated by cgit (git 2.34.1) at 2024-11-12 07:25:22 +0000