[Spice-devel] spice server: connection events

[Vinzenz Feenstra]

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