Skip to content

Fix a pair of related bugs in Server/ClientAssociation::receive#686

Closed
pgimeno4d wants to merge 1 commit intoEnet4:masterfrom
pgimeno4d:fix-max-pdu-len-receive
Closed

Fix a pair of related bugs in Server/ClientAssociation::receive#686
pgimeno4d wants to merge 1 commit intoEnet4:masterfrom
pgimeno4d:fix-max-pdu-len-receive

Conversation

@pgimeno4d
Copy link
Copy Markdown
Contributor

The problem can be quickly spotted by comparing the sync and async versions of ClientAssociation::receive() in the source:

Sync version:

match read_pdu(&mut buf, self.acceptor_max_pdu_length, self.strict)

Async version:

match read_pdu(&mut buf, self.requestor_max_pdu_length, self.strict)

One says "requestor" and the other "acceptor"? That can't be right; both sync and async should use the same criteria. So which one is right? It's checking what "we" are able to receive, and since the client is the one that makes requests, and thus the requestor, requestor is right and acceptor is wrong. That is, the sync version is wrong.

The exact same problem happens in ServerAssociation::receive:

Sync version:

match read_pdu(&mut buf, self.acceptor_max_pdu_length, self.strict)

Async version:

match read_pdu(&mut buf, self.requestor_max_pdu_length, self.strict)

The server is the acceptor, so in this case the async version is wrong.

The maximum PDU's length was being checked against the wrong value in the sync version of the client, and in the async version of the server.
@Enet4 Enet4 added bug This is a bug A-lib Area: library C-ul Crate: dicom-ul labels Sep 17, 2025
@Enet4 Enet4 self-requested a review September 17, 2025 09:35
@Enet4 Enet4 added this to the DICOM-rs 0.9 milestone Sep 17, 2025
@naterichman
Copy link
Copy Markdown
Contributor

naterichman commented Sep 17, 2025

I think this should be fixed in #679 see here

I changed the Association structs to store a single max_pdu_length which is the minimum of the configured requestor, and the acceptor, then this is used in all of the read_pdu-esque methods

Edit: Link doesn't show up in diff view very well, linking the code on my branch here and here for client, similar for server as well

@pgimeno4d
Copy link
Copy Markdown
Contributor Author

I agree that #679 fixes it. I'm not sure to fully agree with the conflation of our and the peer's max_pdu_length, but it's not wrong either, so no objections.

I'm not sure whether to keep this open. I guess it depends on whether there will be a 0.8.3. If not, please feel free to close.

@Enet4
Copy link
Copy Markdown
Owner

Enet4 commented Sep 18, 2025

I'm not sure whether to keep this open. I guess it depends on whether there will be a 0.8.3. If not, please feel free to close.

The next version planned is 0.9.0, as we've already started merging breaking changes. On the other hand, I have yet to to make the complete assessment of which PRs will enter. Only those on the 0.9 milestone are practically guaranteed to be included, but I might add more in the meantime.

As for the release proper, I understand that it's been a while since the last one, so hopefully I can drop it before the end of the month. Let's see how things go. :)

@Enet4 Enet4 removed this from the DICOM-rs 0.9 milestone Oct 1, 2025
@Enet4
Copy link
Copy Markdown
Owner

Enet4 commented Oct 1, 2025

I will consider #689 instead, which fixes this bug and improves a few other things around max PDU length negotiation. Thank you for detecting the bug and working on it nevertheless!

@Enet4 Enet4 closed this Oct 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-lib Area: library bug This is a bug C-ul Crate: dicom-ul

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants