This is happening if the client is given a plain "port", which should not happen if the server wants to enforce only SSL. Also, the server can tell us already if the channel is secured (SPICE_LINK_ERR_NEED_SECURED), and this makes controller information redundant. How much cycles are we talking about? saving 100ms isn't going to make a difference for users and/or PM (tbh, I am not a TCP expert, but I wouldn't be surprised the lower layers keep a little link, so switching port could be like sending extra messages without much delay...?). I am not saying this shouldn't be fixed, but we need real arguments to prioritize this correctly.

A real improvement would be to stop this quite unnecessary plain vs secured port, and use a single port instead whose security is enforced by the server, which I think is doable with little change on protocol:

- client connects, send link with a flag CAN_SWITCH_SSL (or bump minor_version)
- server wants SSL, send EER_NEED_SECURED and wait for TLS handshake
- client initiates TLS handshake

That would avoid the need for an extra port & argument, freeing a little bit a scarce resource (port number) and simplifying spice usage a little bit

David, is "default" a specified value of the controller SECURE_CHANNELS message? in spice-gtk commit 26fc5d9f611ac0839eec2fd4242a446d8e96ce8c, I added "all", which seems to be supported by spicec.

How RHEVM let you set default, all, X etc?

I see a distinction between "default" and "all": "all" should require all channels to be secure, "default" should switch behaviour to try secure first and fall back to plaintext (current behaviour is vice versa).

Since RHEV-M doesn't have this sorted out yet: bug 874728, bug 879358, this bug could be rather solved by another option that would indicate where the client should connect first if the channel isn't specified to be secure namely*; or to simply connect to secure channel first (because it seems that not so many people have interest in detailed configuration options and majority of users use TLS for all connections because RHEV/oVirt since their 3.1 versions do so).

* that is, because such configuration model is better to grasp and libvirt already uses it - as is noted in the linked bugs

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

David, I don't see a clear benefit in supporting "default" now that "all" is implemented. The reconnection time lost is really not an issue imho. Maybe move this bug upstream?

I'd wontfix this one.

ok, let's do that