> That's probably because the limit is not entirely fixed in any browser afaik, > but 6 is typically the "long term" limit for desktop browsers at least, that > can be overriden at times for specific (short-term) reasons. Ok, thanks. I have not seen that kind of information previously. So then it should probably be ok to use a lot more connections for a short-term. Good!
> If you are doing "browser-like" operations with libcurl, you are probably > better off capping the amount somewhere, yes. I don't think libcurl needs to > set that default for you though. A lot of users use libcurl in non-browser > use cases and for those a sensible limit might be something completely > different. Yeah, I would probably need to cap it to some limit. (I guess this option is only effective for non-multiplexed connections?) > If you didn't set a limit for curl, it doesn't care and then there's no > ceiling. Ok, I accept your word for it. In any way it doesn't cause an issue for us. I'll probably set a max-limit of maximum 64 connections anyway. But as far I can see, there are 64 connections opened almost at once (it differs slightly, less than 20 ms at most, probably because requests are placed at slightly different times). No connection has reached the connect phase before all connections has been opened and started executing dns lookup. (And definitely no transfers has been completed, so there are no consecutive requests being placed from early finished transfers.) It might be possible that we place exactly 64 requests at once every time when we start a session, but it's not very likely I would say (we probably place more). /Daniel -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
