Click here to Skip to main content
16,015,583 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I have a hardware device that acts as a server and communicates with TCP (Socket). After connecting to the device the device will disconnect if there has been no communication for 5 seconds. This is because it must allow other client programs to connect to it when the device is not used.

Lets assume I will use an Asynchronous Client as described in this example: Asynchronous Client Socket Example. How can I modify this example to handle a server that disconnects after 5 seconds (if there has been no communications)? Should I like the example create a new socket and close it for every single command I sent to the server? The hardware device I use collects real time data so maybe create/close for every command could give a to big delay. If I just write to the device when it is disconnected (and the client program don't know when the server has disconnected) then I will get some exceptions and I'm not sure how to handle this and as fast as possible continue with sending the new command.

Regards
Henrik

What I have tried:

I have tried the example https://msdn.microsoft.com/en-us/library/bew39x2a(v=vs.110).aspx but gets too many exceptions when the device has disconnected and I never know when it is disconnected. Only when I collects real time data I will send a new command every second (< 5 seconds) and then the device will not disconnect.
Posted
Updated 26-May-16 22:18pm
Comments
Sergey Alexandrovich Kryukov 26-May-16 18:29pm    
Is it really that bad as you describe it? Normally, a TCP listener allows multiple connections. I can understand that for a device is makes no sense, because only one client can sensibly control the device and perform, say, data acquisition. But then disconnecting of the device would make no sense; instead, you should better permanently use the same client, always connected to the device.

As you can see, in both cases, I cannot see any sense in disconnection. Am I missing something?

Even if you need disconnections, I have no idea what makes you thinking that server side should disconnect the client. Don't you see the lack of logic here? The active part is always the client. It's the client side which performs connection. Why not disconnection?

—SA
George Jonsson 26-May-16 18:45pm    
Very true.
Henrik R L 27-May-16 3:18am    
Hi
I would also be happy if the HArdware Department did not disconnect the device after 5 seconds without communications. But they say that if the client program on computer A does not close the connection (maybe because of a crash og because the employee on computer A has gone on holiday) then the employee on computer B can never use the device. The device can only handle one connection at a time. So a client software error or an employee error must never lock the device like forever. Then the device is independent of software and employee.
George Jonsson 26-May-16 18:31pm    
Do you need an asynchronous client for this?
At least it might be easier to start with a synchronous client for finding out how to handle the exceptions.
Basically you need to close the port when you get an exception and then check the connection status before sending a request. If it is not Open, then you need to fix that.
Sergey Alexandrovich Kryukov 26-May-16 23:01pm    
Another point to it: I always advise to dedicate some separate threads to communications. They are needed for different reasons anyway. For example, a server side usually need one to listen to new connection, and at least another one for communications themselves (network I/O, read/write). Fixed number of threads which are not added and not terminated anymore during most of the runtime make threading more controllable and predictable.

Closing the socket on exception is a valid technique; and the same thread used for working with the TCP channel can be reused after re-establishing the connection, because you simple handle the exception and return to next iteration in the outer loop.

—SA

1 solution

It is a bit difficult to give good advice as I don't know exactly what type of device it is and how the clients are using it.

You do have a few options, though.

1. Handle every possible exception and reconnect if one occurs.
I know this is not what you want to do, but it is one possibility.

2. Open and close the connection for each command.
Maybe not the most efficient method as it creates a lot of overhead.
If it is feasible or not only you can find out by measuring the connection times etc.

3. Open and close the connection for batch jobs
Let's say the client want to get data from the device for the next 30 seconds, then keep the connection open, send the commands and receive the responses for the duration and then close the connection.
Again, I don't know anything about the behavior of the client software, so maybe it can be a solution or maybe not.

4. Add a timer on the client side as well.
Then you monitor the communication and reset the timer every time a command is sent to the device. If nothing is sent the last 5 or (4.9) seconds, an event is fired and the client closes the connection.

5. Implement a back channel between the client and the server.
This basically works in the fashion that the client also has a server part, so when the client connects to the device, the device connects back to the clients server part.
The only thing this server part is doing is to wait for a shut down command, so when the devices timeout expires, it sends the shutdown command and then closes the connection.
The clients server part receives it and closes its connection to the device.
Of course the client needs to send a shutdown command as well before closing the connection, otherwise the device will be in the same situation as you are now.
Maybe not the most elegant of solutions and it requires changes on the device side as well.
On the other hand, you already have an abnormal client-server relationship so why not mess it up a bit more. :)

At least I hope I can trigger some ideas for you to continue on.
Good luck with that beast.
 
Share this answer
 
v3

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900