[Interest] QTcpServer stop accepting connections

Etienne Sandré-Chardonnal etienne.sandre at m4x.org
Thu Sep 5 17:04:20 CEST 2013


Using browsers to test a QTcpServer is not a good idea, I remember having
similar headaches when I tried. Their behavior is too complex for that.

A simple tool such as a basic FTP server is more simple.

Etienne


2013/9/5 Benjamin Zeller <zeller.benjamin at web.de>

> Ok i just found out what the problem is.
> Its a "feature" of chrome and firefox, they only open
> a few connections to a server and reuse them later.
>
> Means even if i send 20 requests the browser will
> split them into bunches of 6.....
>
> What a waste of time ....
>
> Thanks for your help.
>
> On 05.09.2013 14:27, Benjamin Zeller wrote:
> > On 05.09.2013 14:09, Etienne Sandré-Chardonnal wrote:
> >> Hi,
> >>
> >> Did you see this in the doc?:
> >> *Note:*The returnedQTcpSocketobject cannot be used from another thread.
> >> If you want to use an incoming connection from another thread, you need
> >> to overrideincomingConnection().
> >
> > In fact we did override incomingConnection().
> > Creating the QTcpSocket manually. But maybe QTcpSockets can not be
> > moved between threads?
> >
> > This is a opensource project so:
> >
> >
> > incoming connection are not queued:
> >
> https://github.com/bzeller/tufao/blob/master/src/priv/tcpserverwrapper.cpp#L28
> >
> > socket is created here (without a parent):
> > https://github.com/bzeller/tufao/blob/master/src/httpserver.cpp#L81
> > https://github.com/bzeller/tufao/blob/master/src/httpserver.cpp#L100
> >
> > pushed to the thread:
> >
> https://github.com/bzeller/tufao/blob/master/src/priv/workerthread.cpp#L56
> >
> >
> > I know moving the socket descriptor would be better but the design of
> > the library does not really fit that approach.
> >
> >
> >>
> >> (From Qt 4.8.1)
> >>
> >>
> >> 2013/9/5 Benjamin Zeller <zeller.benjamin at web.de
> >> <mailto:zeller.benjamin at web.de>>
> >>
> >>      Hello again,
> >>
> >>      ok after digging some more its clear that the E_AGAIN or
> E_WOULDBLOCK
> >>      error means that there are no connections available to open. That
> makes
> >>      no sense because i opened 20 connections in a row, but only the
> >>      first 6 are handled and then the following 6 and so on.
> >>
> >>      What could possibly delay the notification of new incoming
> connecions
> >>      until another one is handled?
> >>
> >>      On 05.09.2013 13:04, Benjamin Zeller wrote:
> >>       > Hello,
> >>       >
> >>       > not sure if i just ran into a bug or if i do something wrong:
> >>       >
> >>       > Basically i have a QTcpServer accepting connections, after a
> >>      connection
> >>       > comes in a QTcpSocket is created and pushed to a workerthread to
> >>      handle
> >>       > it (moveToThread).
> >>       >
> >>       > But after 6 connections the QTcpServer stops accepting
> connections
> >>       > (seems to be releated to receiving a EAGAIN error) until the
> first 6
> >>       > are served (but i openend 20 connections at once from my
> testcode).
> >>       >
> >>       > Then it continues with the next 6 and i'm pretty sure the
> mainloop is
> >>       > not blocked, because when i pause with the debugger its always
> >>      waiting
> >>       > inside exec().
> >>       >
> >>       > This happens on Linux, i did not test yet with other operating
> >>      systems.
> >>       >
> >>       > Anyone ran into something similar?
> >>       >
> >>       > _______________________________________________
> >>       > Interest mailing list
> >>       > Interest at qt-project.org <mailto:Interest at qt-project.org>
> >>       > http://lists.qt-project.org/mailman/listinfo/interest
> >>       >
> >>
> >>      _______________________________________________
> >>      Interest mailing list
> >>      Interest at qt-project.org <mailto:Interest at qt-project.org>
> >>      http://lists.qt-project.org/mailman/listinfo/interest
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Interest mailing list
> >> Interest at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/interest
> >>
> >
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
> >
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130905/a53056c7/attachment.html>


More information about the Interest mailing list