Being on the embedded side, I can see why he wants only one client at a time.
It coudl be that he has a serial protocol that is not going over TCP, where
there is no idea of multiple clients.
He should be able to set maxPendingConnections to 0. But as the docs say "but
the operating system may still keep them in queue"
There is no reason why you have to respond to a connection. You could wait
until your 1st connection is done, letting the accepted connection wait. Also
implement a time-out so that you'll delete accepted sockets if you continue to
ignore them.
Perhaps you could better describe your situation?
________________________________
From: Konrad Rosenbaum <kon...@silmor.de>
To: interest@qt-project.org
Sent: Tuesday, June 12, 2012 3:48 PM
Subject: Re: [Interest] QTcpServer - One connection per port
Hi,
On Tuesday 12 June 2012 11:14:54 Gopalakrishna Bhat wrote:
> I am trying to use QTcpServer to accept connection from only one client at
> a time, but i'm not able to do so.
>
> I tried setting setMaxPendingConnections to one but then
> also waitForConnected on the second client returned true. I want
> waitForConnected to return true only for the first client.
>
> Any I idea what I am doing wrong?
Two ideas: either you are solving the problem on the wrong layer, the wrong
way or you are solving the wrong problem.
As Thiago wrote: it is not possible to tell the OS to accept only one
connection. It's in the spec for TCP: it assumes that servers actually want to
serve data to clients...
Wrong layer: some protocols solve this problem by accepting the connection,
then sending the second client a message that they do not intend to allow this
connection to proceed and optionally a reason for this rejection, then they
close the connection.
The wrong way: how about as soon as a new client connects - kick the old
client. This may be easier to implement for some problem spaces. Of course it
produces new problems, like the possibility of (a different kind of) DoS. It
may be worth considering both variants and then decide which one has fewer
drawbacks.
Wrong problem: the need for having only one connection is often a serious
design problem in the protocol. There are hundreds of scenarios how single-
connection protocols can screw up, for example if a network link is lost the
server may not notice the problem for hours - during that time you will not be
able to connect another client. It may be a good idea to try to fix the
protocol to handle multiple concurrent connections.
Konrad
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
