Hey, First, thanks for your feedback, On Wed, Jun 24, 2015 at 09:58:03AM +0200, Vinzenz Feenstra wrote: > Currently when anyone establishes a connection to the port the spice server > emits the 'connected' event, once the right password/ticket etc is passed > and the proper connection is established, the spice server emits the > 'initialized' event and last but not least when someone disconnects the > 'disconnected' event is triggered. > > Now so far so good. Now here are the problems I have been encountering with > it over the time with it: > - If someone randomly connects to the port (e.g. on a public internet facing > host with random connect attempts due to port scans, intrusions etc) the > connected and disconnected events are passed all the time. > The same applies for invalid password connections. Yes, connected is emitted very early as soon as a TCP connection is established. For your usecase, it seems it would be better to wait until the SPICE link negotiation succeeded before emitting it > > - Receiving connected, initialized and disconnected events for every channel > separately. While this might make sense in some way, as there are multiple > established connections by spice, there's the problem, that we want to react > on that event, however basically are getting our code triggered multiple > times as we do not seem to know what channel was actually affected. On the spice-server side, we forward a data structure with the ID/type of the channel affected by the event, but I'm not sure the QEMU side forward this information when emitting the event. If the channel type was available in the event information, you could filter for events occurring on the main channel which would be enough for your needs I think. > > - Seamless/live migrations: On seamless/live migrations from one host to > another, we're also having the issue that the disconnected events are > passed, which again might make sense from the connection level point of > view,but not from a session point of view, as the spice session was > transferred to another host and the client obeys and reconnects. Yup, seems to be missing indeed. > > > After talking with David Jasa about the issue, I think a potential solution > for this issue would be to introduce a new set of events, which are easier > for applications to keep track of and avoid to handle those problems. > The spice server should be able to track sessions for a client, and should > be able to emit events accordingly to it. So I would propose to emit > session-started and session-ended events and only once per session and not > on a connection basis, plus that the session-ended shall not be passed when > a migration to another host was the reason for disconnections. Ok, could you file this in an upstream bug on bugs.freedesktop.org ? Christophe
Attachment:
pgpqeUPMuJ3E4.pgp
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel