From 950306fca00af2ea68f21e7873a227694559cb95 Mon Sep 17 00:00:00 2001 From: Linus Nordberg Date: Wed, 18 Jan 2017 14:25:26 +0100 Subject: Use a listen(2) backlog of 128. There's a chance that incoming (legitimate) connections arrive faster than what it takes to spawn a new thread and get back to listen(). Therefore we should ask the stack to queue at least one entry, i.e. use a backlog value of at least 1. There's arguable also a chance of more than two concurrent incoming connections, which would make a case for a backlog value greater than one. A reasonable high value seems to be 128, which also is what SOMAXCONN is on many unix systems. In the choice between 1 and 128, an argument against the higher value is that it may mask the potential problem of spending a long time serving incoming connections. Being reasonably confident that radsecproxy is efficient when it comes to serving incoming connections, by handing them off to a newly spawned thread, I think that 128 is a fine choice. Closes RADSECPROXY-72. --- ChangeLog | 3 +++ 1 file changed, 3 insertions(+) (limited to 'ChangeLog') diff --git a/ChangeLog b/ChangeLog index 78e2160..10b294c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,4 +1,7 @@ 2017-10-?? 1.6.9 + Misc: + - Use a listen(2) backlog of 128 (RADSECPROXY-72). + Bug fixes: - Completely reload CAs and CRLs with cacheExpiry (RADSECPROXY-50). - Tie Access-Request log lines to response log lines (RADSECPROXY-60). -- cgit v1.1