And, more practically: You cannot be 100% certain. Your API/library needs to expose the possibility of failure to the client. Pretending that re-trying will always work is not going to work, and the client is likely more able to make the right determination of what to do than your library is, because it has more information.

I previously have used UDP, building from the ground up to include features like that along with the reliable delivery mechanism (session security, timing statistics, connection keep-alives in lieu of traffic, lower priority file xfers, App level throttling notifications, thread/process friendly minimal-locking features, msg-aggregation/ connection-postboxing, connection disruption notifications, etc...) All integrated within the Networking thread for efficiency (example is : connection timing statistic ping/reply being handled directly to cut out app level delays and maintaining the statistics a higher App level would make use of). Reinventing the wheel I suppose, but I was attempting to squeeze out as much capacity/efficiency for a application that did alot of inter-server traffic.

Well...

I have callback function pointers inside my connection-manager class for the user to set. Like onConnect, onTimeout and stuff like that. I know it's very basic, but I'm hopeful it'll suit my needs ^^. If not, I will expand it along the way. It's definitely something to get started with. I've got lots of graphical, physical, audio and game-related things to take care of as well... and now with networking in mind, I'm gonna have to restructure the whole thing more or less completely, I guess.

A big 'gaaaah!!' is optimizing for multiple cores (lock issues) where you have only one Network thread (with Affinity) that then all the higher level App threads work through it (again for high performance needs that might not exist for less stressed game mechanics).