Hi, Though implementing this feature using multiple instances of the core data structures, one instance per client, is straightforward and comprises a clean solution, I think that we should implement a more parsimonious solution with respect to memory and cpu, so we can support a large number of clients. We can keep only one instance of the surfaces, trees, GLZ dictionary, etc., and for each client we will hold a pipe. In addition, we should avoid re-encoding the same bitmap for each client it is being sent to, and instead keep the encoded result and send it instantly. This solution raises other issues that need handling, e.g.: * When decoding a GLZ image, the dictionary at the client side must be the same as the one that was at the server side at the moment of encoding that image. However, the stream of images that is sent to each client is not necessarily identical (due to "covering" of rendering commands that haven't been sent yet), and thus, the dictionary in the server might not be consistent with the ones in the clients. One possible solution is to enforce identical dictionary in all the clients: (1) if an image was previously removed from a client sending queue, we will not use GLZ when sending it to another client (2) if an image was previously sent to a client using GLZ, we will enforce sending it to all the other clients. * the pixmap hash at the server side is not an heavy memory consumer, but if we decide to keep only on copy for it, we need to keep it consistent with all the clients, similarly to the GLZ dictionary. * For supporting jpeg compresison in WAN, we will need to store surface_client_lossy_regions for each client.
Cheers, Yonit. p.s. this feature made me think that separating our channels' logic (mainly the red_worker), from the sending queue(s), to different threads, may enhance Spice's performance, even for one client. Why shouldn't we try to send data in the pipe to the client while we are processing commands pulled from the driver? ----- Original Message ----- From: "Alon Levy" <[email protected]> To: [email protected] Sent: Sunday, May 8, 2011 3:10:56 PM Subject: [Spice-devel] [RFCv5 00/47] server: multiple client support changes from previous (v4) after Marc-Andre's review: Surfaces struct renamed to RedRender patch count reduction. reduction of argument count (makes search replace patches more readable too) some other cleanups. I'm sure I missed a few. to turn on multiple client support you need to set SPICE_DEBUG_ALLOW_MC=1 (or any value). tested the handle_dev patch, it seems rendering is not correct with this patch series, see comment on last patch. Still a lot of todos. Tree: git://anongit.freedesktop.org/spice/spice server_multi_client.v5 Alon Levy (47): server/main_channel.c: set NET_TEST_STAGE_INVALID=0 explicitly (TODO - the rest) server/red_channel: renames to use _proc postfix consistently server/red_worker: drop red_pipe_add_tail, use red_channel_pipe_add_tail server/red_channel (all): introduce RedChannelClient server/red_worker: introduce {display,cursor}_is_connected server: move pipe from RedChannel to RedChannelClient server/main_channel: use MainChannel in sig server/red_channel: workaround for fast client disconnect bug (TODO - real fix) server/red_client: clear pipe on disconnect server/red_worker: release PIPE_ITEM_TYPE_VERB in display channel server/main_channel+reds: make main_channel_init return MainChannelClient server: Add RedClient server/reds: add concept of secondary channels server/main_channel: move latency and bitrate to channel client server/main_channel: move ping here from reds. server/main_channel: move connection_id from reds server/red_channel: ignore error if already shutdown server/red_channel: introduce pipes functions server/main_channel: support multiple clients server/inputs_channel: support multiple clients server/red_tunnel_worker: trivial multi client support server/smartcard: support multiple clients server/red_worker: split RedRender from RedWorker server/red_worker: cleanup server/red_worker: split display and cursor channels server/red_worker: remove more direct access to RedChannelClient.rcc server/red_channel: add pipe_size helpers server/red_channel: introduce client ring in RedChannel server/reds: add RedsState.allow_multiple_clients server/red_worker: introduce RedSurfaceReleaseInfo server/red_worker: add ref counting to RedDrawable server/red_worker: start using RENDER_FOREACH server/red_worker: whitespace fixes server/red_worker: copy and free new surfaces after first client server/red_worker: get_streams_timeout: go over all clients server/red_worker: move free from display_channel_send_item to _release_item server/red_worker: split cursor pipe item from cursor item server/red_worker: remove forced disconnect on connect server/red_worker: add cursor_channel_client_disconnect server/red_worker: red_current_add_equal: add dcc null checks server/red_worker: on_new_display_channel_client: push ack, cleanup server/red_worker: give each client a different id for caches server/red_worker: DEBUG_CURSORS (temp) server/reds: use ALLOW_NO_SSL define externally to trigger debug only DEBUG_GENERATE_NULL_KEY (temp) server/reds: DEBUG: add a define for working with no SSL (good for valgrind) (temp) client/red_channel: DEBUG: allow no SSL usage (useful for valgrind) server/red_worker: handle_dev_update: for all clients (checkme) client/red_channel.cpp | 40 +- server/inputs_channel.c | 151 +- server/main_channel.c | 626 ++++--- server/main_channel.h | 47 +- server/red_channel.c | 1027 ++++++++--- server/red_channel.h | 195 ++- server/red_client_cache.h | 58 +- server/red_client_shared_cache.h | 48 +- server/red_dispatcher.c | 39 +- server/red_dispatcher.h | 7 +- server/red_parse_qxl.h | 1 + server/red_tunnel_worker.c | 403 +++-- server/red_worker.c | 3877 +++++++++++++++++++++++--------------- server/red_worker.h | 2 + server/reds.c | 198 ++- server/reds.h | 16 +- server/smartcard.c | 196 +- server/snd_worker.c | 24 +- 18 files changed, 4365 insertions(+), 2590 deletions(-) -- 1.7.5.1 _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
