I'm not sure this really makes sense. You're talking about retrying on failed publishes, yet TCP doesn't have a concept of publishing. Merely message transfer. So you could be publishing, or you could be requesting info.
e.g. HTTP over TCP has the verbs GET/PUT/POST (amongst others). All of these run over TCP. Only two actually write something (PUT/POST). And only PUT is supposed to be idempotent (that is to say, you should be able to the same operation again and again with the same result). If you POSTed repeatedly, I'd expect to republish something and create a new version on the server for every POST.
And the above are only recommendations for how PUT/POST are implemented. I wouldn't want an HTTP library to assume this on my behalf.
So the concept of retrying messages at the TCP layer is mistaken (note that TCP will resend packets etc. making up a message). This is a higher-level function, which may use TCP at a lower level. e.g. I've written my own wrappers around HTTPClient to retry PUTting when my remote server becomes temporarily unavailable or reports an error (I'm not sure a retrying HTTP library exists)