On Fri, Dec 04, 2015 at 09:45:04AM +0200, Michael S. Tsirkin wrote: > On Wed, Dec 02, 2015 at 02:43:58PM +0800, Stefan Hajnoczi wrote: > > 1. The 3-way handshake isn't necessary over a reliable transport > > (virtqueue). > > Spoofing packets is also impossible so the security aspects of the 3-way > > handshake (including syn cookie) add nothing. The next version will > > have a > > single operation to establish a connection. > > It's hard to discuss without seeing the details, but we do need to > slow down guests that are flooding host with socket creation requests. > The handshake is a simple way for hypervisor to defer > such requests until it has resources without > breaking things.
I'll send an updated virtio-vsock device specification so we can discuss it. VMCI simply uses sk->sk_max_ack_backlog in net/vmw_vsock/vmci_transport.c. If backlog (from listen(2)) is maxed out then the connection is refused. The same would work for virtio-vsock and there is no advantage to the 3-way handshake. > > 2. Credit-based flow control doesn't work for SOCK_DGRAM since multiple > > clients > > can transmit to the same listen socket. There is no way for the clients > > to > > coordinate buffer space with each other fairly. The next version will > > drop > > credit-based flow control for SOCK_DGRAM and only rely on best-effort > > delivery. SOCK_STREAM still has guaranteed delivery. > > I suspect in the end we will need a measure of fairness even > if you drop packets. And recovering from packet loss is > hard enough that not many applications do it correctly. > I suggest disabling SOCK_DGRAM for now. I'm not aware of a SOCK_DGRAM user at this time. Will disable it for now.
signature.asc
Description: PGP signature
