On 06/24/2015 12:30 PM, Christophe Fergeau wrote:
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.
I was checking it, and now I see that the problem seems to lie on the
libvirt side, which strips the really helpful data like which channel
and what is the remote port.
With that information I would have been able to handle those things much
nicer. Well I will redirect that portion to libvirt then :-)
- 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 ?
I have file the bug here: https://bugs.freedesktop.org/show_bug.cgi?id=91085
Christophe
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel