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.

3 files changed, 5 insertions, 2 deletions

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).
diff --git a/tcp.c b/tcp.c
index 5f5114b..6f971f6 100644
--- a/tcp.c
+++ b/tcp.c
@@ -353,7 +353,7 @@ void *tcplistener(void *arg) {
     struct sockaddr_storage from;
     socklen_t fromlen = sizeof(from);
 
-    listen(*sp, 0);
+    listen(*sp, 128);
 
     for (;;) {
 	s = accept(*sp, (struct sockaddr *)&from, &fromlen);
diff --git a/tls.c b/tls.c
index 65c8253..567a6be 100644
--- a/tls.c
+++ b/tls.c
@@ -467,7 +467,7 @@ void *tlslistener(void *arg) {
     struct sockaddr_storage from;
     socklen_t fromlen = sizeof(from);
 
-    listen(*sp, 0);
+    listen(*sp, 128);
 
     for (;;) {
 	s = accept(*sp, (struct sockaddr *)&from, &fromlen);