Server: allow immediate reuse of http port

[jpm-canonical]

Add the SO_REUSEADDR flag to the http port, similar to what is done on the GRPC port here.

Related:

• Resolves Misc. bug: Reverse port not properly closed after SSE stream is closed #19758

AI disclosure: Copilot (Claude Sonnet 4.5) was used to triage and fix the issue.

[ngxson]

This seems to break all windows build configurations

[jpm-canonical]

Windows builds failed because the value for the socket flag is an int, and it can't be interpreted as a const char. The variable is now changed to a const char. Building succeeds on Linux, as well as using Mingw for Windows.

[Green-Sky]

When SO_REUSEADDR is set on windows, it allows another process to "steal" the address, while in use.

see eg https://learn.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse#using-so_exclusiveaddruse

[jpm-canonical]

@Green-Sky thanks a lot for the comment and link to the docs. I agree that using SO_REUSEADDR has a possible negative side effect. The initial implementation followed what is already being done in the GRPC server code.

I investigated this further, and using SO_LINGER with a timeout of 0 seconds also solves the problem mentioned in #19758. This does not introduce the same port hijacking possibility as SO_REUSEADDR does.

[ngxson]

I restarted the failed CI, seems to be unrelated to this change. will merge this once everything is green.

@Green-Sky feel free to take a quick look

[ngxson]

The same workflow failed twice for the same reason, there should be a problem with this PR: https://github.com/ggml-org/llama.cpp/actions/runs/22354279984/job/64980570539?pr=19763

[jpm-canonical]

@ngxson indeed. Looking at that test it does use streaming, so most likely touching the same code path. We will need to investigate better what is going on.

[jpm-canonical]

I rebased on to the master branch yesterday, and the test that failed before is passing - both locally and in CI:
https://github.com/ggml-org/llama.cpp/actions/runs/24463225944/job/71483177633?pr=19763#step:6:205

There are some other CI test failures, but those seems unrelated to this PR.

[ServeurpersoCom]

Doesn't this conflict with #21056 ?
set_socket_options overwrites the previous callback in cpp-httplib, so calling it again in start() drops the SO_REUSEADDR / SO_REUSEPORT setup from init() and silently disables --reuse-port.

[jpm-canonical]

@ServeurpersoCom I believe you are correct. When I made this change that flag and code block did not exist. Let me refactor this PR to properly handle the flags.

[jpm-canonical]

Looking into this now, we see #21056 introduced the SO_REUSEADDR socket option (see this line). Earlier in this PR we discussed it and decided that is not a good approach, and rather use the SO_LINGER option.

Because SO_REUSEADDR is currently being set on the master branch, and that also solves the underlying issue related to immediate reuse of the socket after llama-server exits, this PR becomes unnecessary. I'll update this branch to add the SO_LINGER in the correct place, but then I will close this PR if I can prove the original issue is solved.

[jpm-canonical]

I tested with both this branch as well as b8808 from the master branch. The original problem is solved, because #21056 intriduced SO_REUSEADDR.