fix Issue 3701 : HTTP streaming support listening at both IPv4 and IPv6 #4265
+214
−37
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Main Changes
In srs_app_server.cpp, I have updated the following components:
api_listener_
apis_listener_
http_listener_
https_listener_
These components have been replaced with SrsMultipleTcpListeners to enable support for multiple port inputs. The new SrsMultipleTcpListeners operate similarly to the original SrsTcpListener but provide enhanced functionality for handling multiple ports.
Considerations
There is a functional relationship between api_listener_ and http_listener_ (as well as between apis_listener_ and https_listener_). Specifically, when the port of api_listener_ matches that of http_listener_, they share the same HTTP multiplexer (http_mux) for efficiency.
With the introduction of multiple port handling via SrsMultipleTcpListeners, careful consideration is required to ensure proper reuse of HTTP components without conflicts.
If the configuration option reuse_api_over_server_ is enabled, the following behavior occurs:
The APIs / and /api/v1/versions are no longer handled by SrsServer::http_handle. Instead, these requests are processed by the HTTP server components.
However, under the new design with SrsMultipleTcpListeners, if there is any overlap between the ports of api(s)listener and http(s)listener, the following issues may arise:
Regardless of the value of reuse_api_over_server_:
An error will occur if the two listeners share any ports.
If reuse_api_over_server_ == true:
Some ports in the range of api(s)listener will be unable to handle requests for / and /api/v1/versions, as these are already managed by the HTTP server components.
If reuse_api_over_server_ == false:
The overlapping ports between the two listeners will result in duplicate definitions for / and /api/v1/versions, causing conflicts.
To address these potential issues, I have implemented logic to enforce one of the following conditions:
There must be no overlap between the ports used by api(s)listener and those used by http(s)listener.
Alternatively, the range of ports in http(s)listener must fully encompass those in api(s)listener.
If neither condition is satisfied, an error will be raised to prevent misconfiguration and ensure consistent behavior.