One problem with that design - a new connection could force an existing
connection to drop in the middle of a critical step. A new connection should
not necessarily force an existing connection to drop if the embedded system has
a proper TCP stack that recognizes when connections go away correctly. If it
does, then the loss of the connection should trigger the software to allow a
new connection through, and otherwise ignore it (this is what I do in my
application as I have a proper TCP stack). If it doesn't have a proper TCP
stack so that TCP connections can get hung when one end goes away, then yes I
would agree that it should then drop the first connection and go to a new
connection - or perhaps, try to ping the first connection to see if it is still
alive before doing so (probably a better solution) and deciding what to do
based on the result.
Regardless of what we suggest in this scenario, he ultimately needs to look at
his software architecture, OS, etc. and decide what the best solution is for
him as it could impact the application protocol, design, etc.
FYI - I use a state machine in the software to track whether or not to allow a
connection. The state machine is tied to the acceptance and loss of a
connection. One use is nearly the same as yours; another is for controlling
some tasks that only one controller client is allowed to do which lock the
system from normal operation (if that client went away, it frees it up for
another to take control and restart the process); though it allow multiple
controller clients to connect for normal operation.
$0.02
Ben
>________________________________
> From: Jason H <[email protected]>
>To: Gopalakrishna Bhat <[email protected]>; "[email protected]"
><[email protected]>
>Sent: Wednesday, June 13, 2012 10:11 AM
>Subject: Re: [Interest] QTcpServer - One connection per port
>
>
>Ah, and so we have to ask the question - what does an additional connection
>mean in terms of your application?
>
>
>I think it best to !assume! that if you get another connection you should drop
>the first. This is because the client software may have restarted. Alternate
>scenarios are that you want to protect the information/transaction that's
>already been started.
>
>
>I would say in 99% of cases the first is the best, so close the current
>connection and start another. It should be easy, especially if you use a
>singleton for the socket... If you get a connection and it already exists just
>delete it.
>
>
>
>
>________________________________
> From: Gopalakrishna Bhat <[email protected]>
>To: "[email protected]" <[email protected]>
>Sent: Tuesday, June 12, 2012 10:44 PM
>Subject: Re: [Interest] QTcpServer - One connection per port
>
>
>
>
>
>On Wed, Jun 13, 2012 at 2:08 AM, Jason H <[email protected]> wrote:
>
>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?
>>
>>
>I want to control my application remotely via TCP. Only one client should be
>able to connect and control my application at a time, hence this question.
>
>Regards,
>Gopalakrishna
>
>
>--
>My blog http://gkbhat.blogspot.com
>
>_______________________________________________
>Interest mailing list
>[email protected]
>http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
>_______________________________________________
>Interest mailing list
>[email protected]
>http://lists.qt-project.org/mailman/listinfo/interest
>
>
>
_______________________________________________
Interest mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/interest
