How to use asynchronous client socket on device that disconnects

Question

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 26-May-16 9:33am

Henrik R L

Updated 26-May-16 22:18pm

Add a Solution

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

Henrik R L 27-May-16 3:38am

I also started with a synchronous TCP/IP. I connected to the device. Then more than 5 seconds will pass (the employee drink some coffee). Then the employee start some job on the client. Then the first thing that will happen is some exception because the hardware device has diconnected. The connection status I think this only gives me the connections status for the last time there was a communication. Not the status at this moment. Then the code is based on exceptions and the communication ends up with a lot of "bad coding" and "bumbing IO". I was just looking for some pseudocode that describes what to do (checks, disconnects, reconnects, recreate sockets etc.) in all scenarios when a client communicates with a device that does disconnect after 5 seconds with no commands sent from the client. And a client must never lock the device (like sending idle commands forever) because the device must always be available for another client to start a real job (no matter if a software error happens on the first client).

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

George Jonsson · Answer 1 · 2016-05-26T22:18:00

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.