RE: General socket question: Would server knows the connection hasbeen broken if client drop the connection without calling close() -- RPG400-L

I guess that means server wouldn't know the connection has been broken
when program ended abnormally without exec the close() api.

No. It means I didn't understand your question, and was asking forclarification.

I guess maybe my response should've been "it depends on how the socket wasclosed." Obviously you know what happens when the close() API closes thesocket. What other possibilities are there?


a) You could use NETSTAT *CNN to close it.

b) You could end the job (as David suggested) or end the subsystem, etc.

c) The network cable could be cut.

d) The power could go out.

e) Some other hardware failure could occur.

When the operating system knows that the connection is being terminated,and is able to react to it, it'll send a packet that contains the FIN("finished") flag to the remote side. This tells the remote program thatthe connection is done.

That's what happens when you end the connection with the close() API, orNETSTAT, the ENDTCPCNN command, ending the job, etc.

However, when the network connection is cut, the hardware fails, the powergoes out, etc, there's no way for the iSeries to send a response backtelling the server that the connection has ended. In that case, theserver program won't have any indication of the problem, and will just sitthere and continue to wait for data.

Unless, of course, "keep-alives" are enabled on the TCP connection. Whenkeep-alives are enabled, data is sent periodically to see if theconnection is still alive. If no response is received to the keep-alivepacket, the server would know that the connection has been dropped even ifthe problem is due to a network cable being cut. Since keep-alives aren'tsent very often, this is usually only used for long-running sessions likeTELNET.

For shorter sessions like FTP, SMTP, etc they usually just time thesockeet out if nothing is received for a given period of time. (maybe aminute or two) and disconnect it.

Well written programs should never assume that they'll receive a FINpacket. They should always have an alternate way of detecting that theconnection is dropped... timeouts or keep-alives are reasonable solutionsto the problem.