Repository navigation
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c55ac40d01
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return {embedded::IoStatus::timeout, 0U}; | ||
| } | ||
| #else | ||
| const auto count = ::send(stream.socket, bytes.data(), bytes.size(), 0); |
There was a problem hiding this comment.
Avoid blocking indefinitely when sending to a stalled peer
On POSIX, the accepted socket remains blocking and this calls send() without first waiting for writability or configuring a send timeout. If an enabled client stops reading while reports continue, its TCP receive window eventually fills and the single-threaded server blocks here indefinitely, preventing connection cleanup, later connections, and potentially SIGINT shutdown. Use a nonblocking socket or the bounded writable-wait pattern already used by the static IED server.
Useful? React with 👍 / 👎.
| (result.status == mms::MmsStaticServerSessionStatus::would_block || | ||
| result.status == mms::MmsStaticServerSessionStatus::timed_out); |
There was a problem hiding this comment.
Do not require a read timeout before staging reports
When an established client sends requests continuously, every poll_once() returns progress or response activity rather than would_block/timed_out, so this condition never calls MmsStaticBrcbConnection::poll(). Captured BRCB events then accumulate and can overflow the retained queue even though the owner remains enabled and connected. Stage a report whenever the session has no buffered input or pending response after servicing the current operation, without requiring the socket to have gone idle for the full receive timeout.
Useful? React with 👍 / 👎.
Stacked follow-up to PR #51. Adds a dedicated desktop BRCB interoperability lab server using the already-reviewed server core: static BRCB object bank, association/Owner lifecycle, periodic GGIO data-change capture, retained queue, asynchronous InformationReport delivery, and two-phase commit only after the full frame is sent. This PR is for lab/external IEC 61850 client interoperability evidence only; it makes no IEC 61850 conformance claim. Keep draft until PR #51 lands and GCC/Clang/MSVC self-tests plus fresh review are green.