Network programming
-
Say i have a server running and several client connected to this server. How to program 1)to detect when a client on purpose power down his PC without closing the connection 2)the client's pc hang causing connection to server be disconnected Thanks in advance
-
Say i have a server running and several client connected to this server. How to program 1)to detect when a client on purpose power down his PC without closing the connection 2)the client's pc hang causing connection to server be disconnected Thanks in advance
-
One possible way is to keep some table to track the last activity time of each client. If it is more than some acceptable window we could assume there is something went wrong with the client.
Thanks Laddie Kindly rate if the answer was helpful
what will be the best timing to consider a connection has broken
-
Say i have a server running and several client connected to this server. How to program 1)to detect when a client on purpose power down his PC without closing the connection 2)the client's pc hang causing connection to server be disconnected Thanks in advance
loke6258038 wrote:
to detect when a client on purpose power down his PC without closing the connection
There is no way to detect a client connection dropped without trying to contact it. If you write both client and server, you could implement some sort of "ping" or "heartbeat" functionality.
-
Say i have a server running and several client connected to this server. How to program 1)to detect when a client on purpose power down his PC without closing the connection 2)the client's pc hang causing connection to server be disconnected Thanks in advance
When you are closing the connection i.e when the user at the client closes the application call a function and indicate the server that the client is closing normally, on the form close method (if it is a winform) communicate to the server saying forced application close. You need to handle form close carefully because even under normal application close form close method gets triggered (this can be handled).
-
what will be the best timing to consider a connection has broken
-
loke6258038 wrote:
to detect when a client on purpose power down his PC without closing the connection
There is no way to detect a client connection dropped without trying to contact it. If you write both client and server, you could implement some sort of "ping" or "heartbeat" functionality.
-
But the contacting the client from the server will not work if they are in different network where the ports are opened from only one side.Which will probably the typical case.
Thanks Laddie Kindly rate if the answer was helpful
If you are concerned with the client dropping the connection, this means that once the connection is opened, you can talk to the client. I don't know the protocol you use, but I suspect it is custom. So, in your communication protocol, you could add a call where the server asks the client if he is still there after some idle time.
-
Say i have a server running and several client connected to this server. How to program 1)to detect when a client on purpose power down his PC without closing the connection 2)the client's pc hang causing connection to server be disconnected Thanks in advance
Hi, In order to catch all cases, I would suggest a heartbeat function (as was already suggested). Some details (drawn from specs I've encountered interfacing with various industrial PLC systems): - If your client sessions don't use persistent TCP connections (if you are using an HTTP request for each transaction, for example), you're correct in noting that you can't contact the client from the server gratuitously. In that case, have the client contact the server with a dummy message with a specific interval (unless it has already talked to the server during the interval) and let the server invalidate sessions that haven't been heard from in, say, twice that interval. - If you do use persistent TCP connections (that stay open for the duration of the client session) you can contact the clients from the server (you can write to the socket from either direction as long as it's open). You could then send an "are you alive?"-message to clients you hadn't heard from in a while - you will get an exception if the TCP/IP stack has given up on the connection, a response if not and the client is alive, no response if the client is dead but the TCP/IP stack hasn't realized it yet. The benefit of this is that you can tune the timer intervals on the server without having to change or inform the clients. Reasonable interval would be application specific, but beware of swamping the server with keep-alives if you could have a lot of clients. One crane controller protocol I use requires keepalives be sent each minute (by both ends) and any party that hasn't heard anything for two minutes closes and gives up on the connection (if it's the client that gives up, it starts attempting to reconnect to the server - this also has a timeout and will be repeated indefinitely, as the protocol is built for stuff that should be connected at all times). Persistent TCP connections are used here. Useful?
-- Peter
-
Hi, In order to catch all cases, I would suggest a heartbeat function (as was already suggested). Some details (drawn from specs I've encountered interfacing with various industrial PLC systems): - If your client sessions don't use persistent TCP connections (if you are using an HTTP request for each transaction, for example), you're correct in noting that you can't contact the client from the server gratuitously. In that case, have the client contact the server with a dummy message with a specific interval (unless it has already talked to the server during the interval) and let the server invalidate sessions that haven't been heard from in, say, twice that interval. - If you do use persistent TCP connections (that stay open for the duration of the client session) you can contact the clients from the server (you can write to the socket from either direction as long as it's open). You could then send an "are you alive?"-message to clients you hadn't heard from in a while - you will get an exception if the TCP/IP stack has given up on the connection, a response if not and the client is alive, no response if the client is dead but the TCP/IP stack hasn't realized it yet. The benefit of this is that you can tune the timer intervals on the server without having to change or inform the clients. Reasonable interval would be application specific, but beware of swamping the server with keep-alives if you could have a lot of clients. One crane controller protocol I use requires keepalives be sent each minute (by both ends) and any party that hasn't heard anything for two minutes closes and gives up on the connection (if it's the client that gives up, it starts attempting to reconnect to the server - this also has a timeout and will be repeated indefinitely, as the protocol is built for stuff that should be connected at all times). Persistent TCP connections are used here. Useful?
-- Peter