[Interest] QTcpServer - One connection per port

[Jason H]

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 <konrad at silmor.de>
To: interest at 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 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/20120612/6dac8d75/attachment.html>