Your research revealed the essential lines from ListenAndServeTLS that basically say:
1. create a tls listener 2. have the server serve using that listener The LimitListener example follows this same pattern, just with net.Listener instead of a tls.Listener. A careful reading reveals that ListenAndServeTLS does not do anything to http.Server that you cannot do from outside the http package. This means that you can implement it in your own code; changing it to fit your needs. Your code will probably flow something like: 1. get a listener 2. limit that listener 3. create a tls.Config 4. tlslistener on LimitedListener with config 5. Server.Serve(tlsListener) I am not sure if it would be better to limit before or after the tls listener. I call this trick expanding convenience functions and explain it in regards to another problem at http://pocketgophers.com/expanding-convenience-functions/ (http://pocketgophers.com/expanding-convenience-functions/). To answer your other questions: I think that tlsListener is not part of the Server structure (so that you could easily fetch it and limit it) is for two reasons. First, it keeps the server and the listener separate. There is no fundamental reason that a single server could not serve on multiple listeners. Second, Serve is basically an infinite loop waiting on Listener.Accept. What would it mean to change the server's listener while it is blocked accepting a new connection? The old listener would be blocking. If a connection was never made to it, the new listener would never accept any connections. The API does give the control you need, just not in the way you looked for it. For that last question, controlling connections is usually done as a way to control the use of some other resource such as cpu, memory, database access, etc. Managing resources must be done at both the OS and server level. What needs to be done depends on what the server needs to do, what hardware it is running on, service level agreements, etc. Sometimes limiting, sometimes expanding limits, sometime increasing performance. Hope this helps. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
