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?
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...
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.
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.
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.
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.