1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/websrvr.c

    From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jun 16 19:06:06 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/76acaac000c1bba5e025f115
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Output the User-Agent header value as a info-level log message

    Useful for tracking (some/most) bots

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Mon Jun 16 19:06:06 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/2d4af7be9e8a92ebbbc4242b
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Reduce contention on protected-int thread_count

    We can capture the new value upon atomic-decrement, use it

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 18 18:01:15 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/4090d823bba9fa4630bd79c2
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Solve the active_clients exceeds configured max_clients issue

    e.g. with [Web] max_clients configured for 200, the following could occur: sbbs: web 0522 HTTP [34.45.142.114] Session thread terminated (220 clients, 378 threads remain, 128627 served)

    The issue was that the active_client count is incremented in the http_session_thread(), but was being checked in the main web server/listening thread.

    So now we'll check in both threads, but allow more HTTPS/TLS client threads
    (10 more) than the configured max, to allow for successfull sending of error 503 (up to a point), while HTTP (non-TLS) connections exceeding the configured max will be immediately dropped without creating a session thread.

    We now no longer increment the client highwater mark for connections that exceed the maximum.

    Also fix send_error() to not log the Connection: close\r\nContent-Length: 0\r\n portion of 503 errors.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 18 18:01:15 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/1f480068adc0ac59c5b4e663
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Apply max connections per IP limit to filter-exempted IPs

    This exemption could (did) cause confusing "works for me" situations when testing max concurrent connections settings that may fail for others.

    So, just because an IP address is listed in ctrl/ipfilter_exempt.cfg, no
    longer means that clients at that IP are exempt from concurrent connection limits (from a single IP address).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Wed Jun 18 21:21:55 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/c0c3dbdf76d91f155a9371ca
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Revert "Apply max connections per IP limit to filter-exempted IPs"

    This reverts commit 1f480068adc0ac59c5b4e6634dc827c52721a7da.

    The other servers exempt ipfilter_exempt.cfg listed hosts still and it looks like I really need gitlab to be exempt from the concurrent connections limit for (all my) webhooks to work reliably since they run in parallel and I can't seem to configure that behavior in gitlab.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Jun 18 21:58:33 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/a43ca30ea674ac77ca98d74e
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Pad "HTTP" to 5 chars for protocol field in log messages

    ... aligning display for easier reading with non-proportional fonts.

    Includes the client's protocol and IP address in JS log messages/errors.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Jul 2 19:09:53 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/2444d7baeedd80af330377b6
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Add protocol and IP address to more log messages (mostly JS-related)

    error and debug-level messsages mostly

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Jul 2 20:42:33 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/b1fc88d375c0a3ba9065162a
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Add protocol and IP address to more log messages

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Tue Jul 8 19:44:37 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/917f4933bd70546570101c75
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Log proper errno value upon lseek() failure

    On Windows, SOCKET_ERRNO and errno are different things.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Thu Aug 7 22:32:51 2025
    https://gitlab.synchro.net/main/sbbs/-/commit/6eed77574f0f016317b68f68
    Modified Files:
    src/sbbs3/websrvr.c
    Log Message:
    Immediately remove client IP from connections list upon session termination

    ... don't wait for all the other logout/off/notification stuff to complete first. These waits before removing the client IP from the connected client
    list were causing error 429 responses from the server even though the browser (i.e. Chrome) was actually opening just 6 connections at a time to the server:

    !Maximum concurrent connections (10) exceeded
    !ERROR: 429 Too Many Requests (line 6979) request:

    The first group of 6 client sessions from the browser had actually completed, but the session threads hadn't fully terminated yet. So now, it is possible to have a high(er) number of session threads than before, but web pages will render more reliably (without having to increase the max connections per
    client setting).

    The test to reproduce this issue was to just to go to www.synchro.net with a fresh browser (nothing cached) or hit Ctrl-Refresh to fully reload the page, and the result was a lot of absent/broken page elements.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net