Why read the line, if you can read the bytes? I added more control of the size of read buffer. If you use input buffering, then let's use output buffering. And I want to know that the server has started.

func (c * Client) GetLocalAddress() net.Addr{ return c.conn.LocalAddr() }

func (c * Client) GetRemoteAddress() net.Addr{ return c.conn.RemoteAddr() }

for get local remote address?

As it currently is, the actual error messages received aren't printed to users. This fixes that.

The New() function can be used in NewWithTLS() as well, I use that function rather than repeating code. This will make future modification easier.

The unneeded go.sum file, which was empty, has been deleted.

Go 1.17 will ignore the GO111MODULE environment variable, so I have added module support and created more error checking.

I attempted to bump the Travis CI to use go 1.11, but the tests are still failing with the automated tests due to the conveyance package. They are working perfectly on my computer running go 1.16, though. I'm still investigating this.

Support creating TLS server. Tested passed with my C# TLS client. Sorry I don't have time to write the unit test for this. Anyone who want to secure TCP connection can use this patch.

NewClientCallback should be called on the new routine. in this way, it will never block new client connection. To test that try to add timer.Sleep in NewClientCallback callback function, this will prevent the server accepting new connection.

There will be some difficulties with integration of this library into another application.

At the moment, it is written in such a way that the library is strictly used for creating a TCP server only. However, I could see instances where one might desire to integrate this library into another application. There are some problems with its current implementation.

• The library implements its own logging, and will shut down the entire program if an error is received that prevents the server from starting. Some programs might want to log data and shut down themselves in a clean, controlled manner. This library prevents this from occurring properly.
• There is no way to stop a server once it's started. If a program integrating this library is intercepting process signals, or is otherwise being shut down through another means, the server won't close cleanly in a controlled manner that will stop accepting connections, clients, disconnect all clients, and terminate all running goroutines the server has spawned. The server will remain active and the goroutine to accept connections, at the very least, will still be operational.

Changes to the server might create some breaking changes to clients relying on it for use, such as if they expect the server to stop the program if it can't initialize, something that isn't wise programming. All go programs should handle errors in a controlled manner.

I would propose these issues at the minimum be addressed, so as to allow for integration of this library into existing applications, as well as to allow for the program to log its own errors properly.