I perused your blog entry you mentioned. It's very interesting and will come in handy in the future. Thank you.
I can appreciate your point of view about accepting the fact that currently listeners are not part of the Server and just proceed to produce code and get it done ASAP. My interim approach will require me to do as you suggested "expand the convenience function" as an entirely different function within my own package. That said, if we: 1)change the Server duck-type's existing ListenAndServeTLS() contents a touch without affecting its API signature 2)add a few new properties to Server's structure 2.1)MaxListenersCount. The global max count of Listener we want. 2.2)MaxListenerPoolsCount. The global max count of ListenerPool we want. 2.3)ListenerPools with the preferred type (ring, array, channel...) 2.4)Each ListenerPool would hold Listeners with the preferred type (ring, array, channel...) 3)When we add a listener to the Server, it would manage the balancing of the listeners across the pools while keeping to the constraints MaxListenersCount and MaxListenerPoolsCount. This would prevent others from having to individually invest effort to "expand the convenience function" on the very same feature request: limiting connections to a tls server. 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.
