summaryrefslogtreecommitdiffstats
path: root/server/red_channel.h
Commit message (Collapse)AuthorAgeFilesLines
* server: add support for SPICE_COMMON_CAP_MINI_HEADERYonit Halperin2012-01-121-4/+31
| | | | | | | | | Support for a header without a serial and without sub list. red_channel: Support the two types of headers. Keep a consistent consecutive messages serial. red_worker: use urgent marshaller instead of sub list. snd_worker: Sound channels need special support since they still don't use red_channel for sending & receiving.
* server: Limit the access to SpiceDataHeader of messages - only via red_channel.Yonit Halperin2012-01-121-14/+10
|
* server/red_channel: introduce urgent marshallerYonit Halperin2012-01-121-1/+26
| | | | | | | | | | When red_channel::red_channel_client_begin_send_message is called, the message that is pending in the urgent marshaller will be sent before the one in the main channel. The urgent marshaller should be used if in the middle of marshalling one message, you find out you need to send another message before. This functionality is equivalent to the sub_list messages. It will replace them in the following patches, when sub_list is removed from Spice data header.
* server: handling semi-seamless migration in the target sideYonit Halperin2011-11-021-2/+4
| | | | | | | | | | (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,proto: tell the clients to connect to the migration target before ↵Yonit Halperin2011-11-021-1/+1
| | | | | | | | | | | | | | | 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: set & test channel capabilities in red_channelYonit Halperin2011-11-021-7/+26
| | | | | | | 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.
* server: fix function prototypesChristophe Fergeau2011-09-051-1/+1
| | | | | | | | 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]
* server/snd_worker.c: add red_channel_client_destroy_dummyAlon Levy2011-08-231-0/+1
|
* server: registering RedChannel in reds, instead of ChannelYonit Halperin2011-08-231-22/+48
| | | | | | | | | | | | | | | | | | | | | | | 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-0/+28
| | | | | 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-28/+20
|
* server/red_channel: introduce client ring in RedChannelAlon Levy2011-08-231-6/+11
| | | | | | | | | | | | | | | | | 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/+7
|
* server/red_worker: multiple client support - base splitAlon Levy2011-08-231-2/+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-1/+1
| | | | | | | | | | | | 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/+14
| | | | | | | | | | 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/main_channel: move ping here from reds.Alon Levy2011-08-231-0/+2
| | | | | | | | | | | | | 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/main_channel: move latency and bitrate to channel clientAlon Levy2011-08-231-0/+1
| | | | | | | | | | | | 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-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: move pipe from RedChannel to RedChannelClientAlon Levy2011-08-231-9/+15
| | | | | | | | | | | | | | | | | | | | | | | 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-40/+69
| | | | | | | | | | | | | | | | | | | | | 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-12/+12
| | | | | | | | | 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/
* server/red_channel: move out_bytes_counter from Outgoing to RedChannelAlon Levy2011-03-021-3/+5
|
* server/red_channel: split Incoming/Outgoing to callback and stateAlon Levy2011-03-021-11/+23
| | | | | | | | 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: add red_channel_disconnect, use in red_workerAlon Levy2011-03-021-0/+2
| | | | replace channel_release_res in red_worker with red_channel_disconnect.
* server/red_channel: add red_channel_{,no_}item_being_sentAlon Levy2011-03-021-0/+8
|
* server/red_channel: add red_channel_send_message_pendingAlon Levy2011-03-021-0/+3
|
* server/red_channel: add red_channel_all_blockedAlon Levy2011-03-021-0/+6
|
* server/red_channel (all): add red_channel_get_headerAlon Levy2011-03-021-0/+7
| | | | | 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/+2
| | | | | | 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-8/+3
|
* server/red_channel (all): add red_channel_get_streamAlon Levy2011-03-021-0/+4
| | | | | 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-2/+18
| | | | | | | | | | 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/+1
| | | | | | | 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/+11
|
* server/red_channel: add more ack apiAlon Levy2011-03-021-0/+3
|
* server/red_channel (all): makes red_channel_reset_send_data privateAlon Levy2011-03-021-2/+1
| | | | 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-3/+3
| | | | | | | | 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: s/RedsStreamContext/RedsStreamMarc-André Lureau2011-02-271-3/+3
| | | | https://bugs.freedesktop.org/show_bug.cgi?id=34795
* server/red_channel: export red_channel_sendAlon Levy2011-02-071-0/+1
|
* server/red_channel: add red_channel_receive (for red_worker)Alon Levy2011-02-071-0/+8
|
* server/red_channel: unstatic red_channel_pipe_clear (for red_worker)Alon Levy2011-02-071-0/+4
|
* server/red_channel: unstatic red_channel_push (for red_worker)Alon Levy2011-02-071-0/+6
|
* server/red_channel: add public red_channel_default_peer_on_errorAlon Levy2011-02-071-0/+2
| | | | for later use in red_worker
* server/red_channel: add red_channel_pipe_add_after (from red_worker)Alon Levy2011-02-071-0/+1
|
* server/red_channel: make client ack window configurableAlon Levy2011-02-071-0/+1
| | | | from red_worker
* server/red_channel (tunnel): change sig of red_channel_handle_messageAlon Levy2011-02-071-1/+3
| | | | for later usage with red_worker
* server/red_channel: make MAX_SEND_VEC 100Alon Levy2011-02-071-1/+1
| | | | | | | | MAX_SEND_VEC was 100 for DisplayChannel's RedChannel implementation which is being replaced with RedChannel in red_channel. So changing from 50 to 100 in red_channel (make this configurble?) - effectively increased memory usage by: (100-50)*sizeof(iovec)*(num_of_channels-2) ==(arch 64bit) 50*16*6 ~ 5k Not terrible.
* server/red_channel: reflect SpiceDataHeader fields in handle_parsed_procAlon Levy2011-02-071-2/+2
|
generated by cgit (git 2.34.1) at 2024-06-07 11:44:33 +0000