Berkley sockets shutdown function, how important?

Question

Hello,

as background I've got an embedded device that talks to a third party server over IP. The code in the third party server is unlikely to change. In a recent release I changed the ip disconnect function to call shutdown() before calling close() (previously it had just called close()). The embedded device disconnects without completing a comms session if certain interrupts occur. When this happens at the wrong point in a session the server is now producing a trace file which, for various reasons, is not acceptable to the customer. This only happens when shutdown is called, the server treats this as a failed to send error (and produces a trace file) while it treats the more abrupt close() as an other end disconnected error which doesn't need tracing.

So the obvious solution is to stop calling shutdown. Mr Barnes' answer in this question gives a good description of the two functions but, if you know that only one process is attached to a particular socket, is there any reason to use shutdown before a close?

Thanks, Patrick

Answer 1

It sounds to me as if "abrupt disconnection" has become part of your communications protocol, which is not a good thing. If the client is running for long after "certain interrupts occur" to decide whether or not to use shutdown() or close() and have that influence what the other end sees, it would be better to update your protocol to reliably deliver a "this session is aborted message."

That said, it's sounding as if this system (i.e., all of the interacting software) has gotten one bit (on the server) frozen badly enough that this sort of change is never going to happen. Probably what you want to do, rather than figuring out what the problem really is, is get a manager to sign off on a quick-and-dirty "just use close()" solution, after explaining to him that you're not really sure what other effects this could have, but things did seem to run ok that way before. (You haven't noticed any other bugs disappear since you made that change, have you?)

Deciding whether to get into a potentially expensive search to see what's really going on here, along with a potentially expensive (politically, if not financially) with some organization on the other end responsible for maintaining that software is really a management decision, not a technical one, though to be made properly it needs to be informed by the technical risks.