qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Multiple QMP socket clients


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] Multiple QMP socket clients
Date: Tue, 11 Oct 2016 16:12:02 +0100
User-agent: Mutt/1.7.1 (2016-10-04)

* Daniel P. Berrange (address@hidden) wrote:
> On Tue, Oct 11, 2016 at 03:17:04PM +0100, Daniel P. Berrange wrote:
> > On Tue, Oct 11, 2016 at 03:08:34PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrange (address@hidden) wrote:
> > > > On Tue, Oct 11, 2016 at 12:26:37PM +0200, Samuel Ortiz wrote:
> > > > > Hi,
> > > > > 
> > > > > On a qemu instance started with a qmp unix socket:
> > > > > 
> > > > > -qmp unix:/tmp/ctrl.sock,server,nowait
> > > > > 
> > > > > I am trying to have multiple clients working on that socket but
> > > > > although the qmp server seems to accept the connections, only the 
> > > > > first
> > > > > connected client gets his request processed. The next client requests
> > > > > will just hang until the first one exits.
> > > > > 
> > > > > Is that an intended behaviour ?
> > > > 
> > > > Yes, the character device code is designed around the idea of a single
> > > > endpoint.
> > > > 
> > > > In the case of the monitor you could work around it by adding multiple
> > > > -qmp arguemnts, each with different socket. Of course you have to make
> > > > sure each client doesn't trample on the other client when doing this.
> > > 
> > > But why does it accept the connection?
> > > I thought you could say only accept a single connection on a socket.
> > > (The backlog parameter to listen(2) but I can't find out listen.)
> > 
> > QEMU won't accept the connection, as while it is still listen()ing on
> > the socket, it is not poll()ing for incoming clients, so will never
> > trigger accept(). The kernel will queue the incoming connection until
> > QEMU starts polling for clients again. From the client POV this is
> > indistinguishable from QEMU accepting the client, but not processing
> > I/O on it.
> 
> Oh, and the backlog parameter to listen() is fairly useless - it won't
> stop new clients getting into an established socket state
> 
>    https://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html

Oh, that's annoying; ok, if that's all we can do that's fine; and I did check 
with
an strace and we do have a :

[pid 22661] listen(9, 1)                = 0

and I do only see a single call to accept4() even though the 2nd telnet
apparently shows it connected.

> QEMU could just accept() all incoming connections and explicitly close
> them if something is already connected, but this just burns CPU really.

It might make failures more obvious than a non-responsive socket.

Dave

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]