I tried just what you mentioned. Unfortunately even my interim solution when it is outside of the net.http package and within mine, there are many services that are not exported meaning I can't use them at all and the variables themselves are inaccessible. I tried copying pasting some functions and tweaking them and I ended up going down a rabbit hole never to get out of. The only way to achieve what I want would be to tweak the original golang sources for net.http.ListenAndServeTLS and stuff surrounding it.
On Wednesday, August 3, 2016 at 9:19:40 AM UTC-4, Nathan Kerr wrote: > > 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.
