fix(socket/rep): correct cleanup on FIN + ping support #140
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When a client is done sending data, it sends a FIN message to the server. This is interpreted by the `Framed` abstraction as an EOF, which means that when we poll it returns `Poll::Ready(None)`. The current logic decides to close to connection on such event, but this is incorrect. The peer is still available to receive a response to the last data that has been sent. This has been now changed so that we try to send and flush all messages in the egress queue. However, pending messages which haven't been handled yet by the consumer of this library are still dropped. We can refine it later
merklefruit
approved these changes
Dec 10, 2025
Contributor
merklefruit
left a comment
merklefruit
left a comment
There was a problem hiding this comment.
lgtm with one pedantic nit
mempirate
requested changes
Dec 11, 2025
Contributor
mempirate
left a comment
mempirate
left a comment
There was a problem hiding this comment.
Good catch. Small nits
mempirate
reviewed
Dec 11, 2025
thedevbirb
force-pushed
the
lore/fix/last-flush
branch
from
1c44c44 to
4756908
Compare
mempirate
approved these changes
Dec 11, 2025
thedevbirb
added a commit
to BuilderNet/FlowProxy
that referenced
this pull request
Dec 15, 2025
This release drops the HTTP server used in FlowProxy for dealing with system requests. Now only the TCP server exists. It marks a breaking change in FlowProxy, because backwards compatibility is not maintained anymore. - The HTTP server on the usual system api port (5544) has been dropped, meaning that also the `readyz`/`infoz`/`livez` endpoint are now unsupported as well. Healthchecks will be performed by sending a special packet to the TCP server, see <chainbound/msg-rs#140>. - As mentioned above, all functionality related to `infoz` endpoint for port discovery has been dropped, and the socket address returned from BuilderHub is assumed to be for the TCP server. - The flag `--system-listen-addr-tcp` (`SYSTEM_LISTEN_ADDR_TCP`) has been dropped. - The flag `--system-listen-addr-http` (`SYSTEM_LISTEN_ADDR`) has been renamed to `--system-listen-addr`, with same environment variable name, and it now is used to bind the TCP server. - The flag `--http.client-pool-size` (`CLIENT_POOL_SIZE`) has been removed since there are no more HTTP clients used for forwarding orders to peers.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When a client is done sending data, it sends a FIN message to the server. This is interpreted by the
Framedabstraction as an EOF, which means that when we poll it returnsPoll::Ready(None).The current logic decides to close to connection on such event, but this is incorrect. The peer is still available to receive a response to the last data that has been sent. This has been now changed so that we try to send and flush all messages in the egress queue.
However, pending messages which haven't been handled yet by the consumer of this library are still dropped. We can refine it later.
This PR also closes #139, by adding a special handling of the string
PING. This means an external service that wants to ping an application running a msg-rs TCP server must send the following bytes:So that they're correctly interpreted according to
Codecimplementation. The response would be just the bytes ofPONG, with encoding: