[Interest] QTcpServer - One connection per port

[BRM]

Or, as in my case, there is only suppose to be one instance of the software coming in over that network connection; and a new connection means the software is running twice; so I just ignore it (e.g. close it). This also allows me to switch the connection, or allow the other program to go away and come back in a proper manner.

Ben




>________________________________
> From: Jason H <scorp1us at yahoo.com>
>To: Konrad Rosenbaum <konrad at silmor.de>; "interest at qt-project.org" <interest at qt-project.org> 
>Sent: Tuesday, June 12, 2012 4:38 PM
>Subject: Re: [Interest] QTcpServer - One connection per port
> 
>
>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
>
>
>
>_______________________________________________
>Interest mailing list
>Interest at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/interest
>
>
>