[Interest] QTcpServer - One connection per port

[BRM]

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 <scorp1us at yahoo.com>
>To: Gopalakrishna Bhat <gopalakbhat at gmail.com>; "interest at qt-project.org" <interest at qt-project.org> 
>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 <gopalakbhat at gmail.com>
>To: "interest at qt-project.org" <interest at qt-project.org> 
>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 <scorp1us at yahoo.com> 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
>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/20120614/6ce8779e/attachment.html>