Making a TCP server safe from crashing clients

[WattMood]

I am writing a (fairly) simple threaded Serial to TCP server using the PracticalSockets library. The function of the program is to share a serial port with many applications by echoing any data over local/remote TCP connections.

The program works but I would like to make it extremely stable as it's a very critical part of a system. In other words I'd like it to be 'crashproof'.

Im having problems when I open up, say, 5 client apps and start force closing them with the System Task Manager. It wont necessarily crash on the first or second forced close, but by the 5th my Network bridge will usually crash.

I have a feeling the socket not being closed properly is the source. I have them in 'try' and 'catch' blocks but am not ever seeing my catch for the socket.receive() chunk of code.

Anybody have experience with solidifying a server, that might have some suggestions???
Also, in the event that it does crash? How could I initiate another instance of the program to start up right away?

[Athar]

I have a feeling the socket not being closed properly is the source. I have them in 'try' and 'catch' blocks but am not ever seeing my catch for the socket.receive() chunk of code.

try and catch? Does receive() even throw any exceptions? I've never heard of this "PracticalSockets" library before, but you should refer to its documentation.

To find out why the program crashes, use the debugger.
If the program aborts with SIGPIPE (Broken pipe), you need to ignore that signal.
Are you handling any exceptions that send() may throw?

How could I initiate another instance of the program to start up right away?

For example by using a shell script that just keeps restarting the server in an infinite loop.
Not the best idea, of course - you should just make sure your program is stable.

[WattMood]

Practical Sockets has very little documentation, but is very simple. Its just a wrapper for WSAsocket and sockets for linux. Im not sure about the linux libraries throwing exceptions but the Windows ones definitely do.

The server is written in CodeBlocks IDE but im not impressed with the debugger...

[Athar]

Impressed or not, that's no reason not to use it.
It will precisely tell you what the problem is. You can use gdb directly from the command line if you so prefer.

[hanst99]

I could swear that both winsock2 and sys/socket are C.

but im not impressed with the debugger

C::B doesn't have a debugger. It uses the one you tell it to. Which is in your case probably MinGW gdb if you're using windows. By the way, are you using Code::Blocks 10.5? If so, scrap it and get the nightly build from the forum. That version of C::B is 2 years old, I have no clue why on earth they even have it on their front page.

[kbw]

Its just a wrapper for WSAsocket and sockets for linux.

Unless this PracticalSockets library is providing something of convenience, there really is no reason to use it, and it may just be getting in the way.

The Sockets library is a standard Unix library that is the standard way of using IP. Linux implements the Sockets library. And Windows implements the Sockets library (as WinSock). So you don't need some library to provide portability unless it's bringing something else to the party (reliability, ease of use, ...), because they're all implementations of the Sockets library. You may as well use Sockets directly.

I would like to make it extremely stable as it's a very critical part of a system.

Are you checking error codes from all calls?

EDIT: I found some stuff on Practical Sockets.
http://cs.baylor.edu/~donahoo/practical/CSockets/practical/

It starts with the quote:
This library was developed for pedagogical use and is not suitable for production applications.

It seems to bring ease of use to the party, that's good. But if it's not production quality, then it's unsuitable for your purposes.

[WattMood]

I use it because its literally the barebones. If i decided to "type it myself" i would end up typing the exact same thing. So its not like i need the library its just the same as if i were to #define a bunch of WIN vs NIX functions.

I took that as base code, added threading for Asynchronous communication and encapsulated it in a class (which pthread and classes are a pain to combine btw since you cant use member functions as a thread without creating proxies that pass pointers to itself blah blah....)

anyway, i found the problem. When I would 'hard' crash the client softwares the thread that would send out (over tcp) the incoming data (from serial) would access a null pointer since the connection had closed.

One of those coding moments where milliseconds matter. I solved the last of my issues by forcing the send command to do an additional check right before sending to make sure the client hadnt dropped out midway through the infinite loop.

[3hM2Nwbp]

If third party libraries aren't a problem, I would recommend either boost asio, or just plain asio. Plain asio is a header-only library so you don't have to worry about building it from source and distributing dependencies. I've used it in a few server applications and it has not failed me yet.

http://think-async.com/

PS. the asio library has been proposed (back in 2005, at least) to be included in the standard C++11 library TR2!