Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NetNamedPipe System.ArgumentOutOfRangeException fix #1100

Merged
merged 1 commit into from
Jun 7, 2023

Conversation

chrjstophoros
Copy link
Contributor

Task<int> ReadAsync(byte[] buffer, int offset, int count, CancellationToken cancellationToken) is now advancing the buffer at the end of the method, just like int Read(byte[] buffer, int offset, int count) does it.

This helped fix a ArgumentOutOfRangeException. I don't know this project good enough however, so I can't really tell if this change makes sense or not.

@chrjstophoros
Copy link
Contributor Author

@dotnet-policy-service agree

@mconnew
Copy link
Member

mconnew commented Jun 7, 2023

@chrjstophoros, how were you triggering this bug? Having a regression test which fails without this fix would be really useful so understanding the failure scenario would really help.

@mconnew
Copy link
Member

mconnew commented Jun 7, 2023

This one's interesting (if you find these sorts of things interesting 😃). I understand why this tripped up on NetNamedPipe and not NetTcp. This only affects streamed mode transfer. When using streamed mode, data is sent in chunks up to (I think?) 16KB. There's a variable length encoded integer sent stating the size of the chunk, then the chunk is actually sent. With NetTcp, we send the size and specify not to send immediately. We basically turn off TCP_NODELAY. This means the OS will buffer the bytes representing the length because it's not efficient to send a few bytes on its own. Then we turn on TCP_NODELAY and send the chunk data. On the receiving side, the data is received in a single buffer with the length attached to the chunk. This means calling DecodeSize will always have some buffer left as the chunk payload will always be received with the chunk size.

For NetNamedPipe, there's no concept of turning on/off TCP_NODELAY, so everything just gets sent immediately. This means the receiver might receive the chunk size without the chunk data in a call to Input.ReceiveAsync. This results in _buffer being empty after DecodeSize is called and EnsureBufferAsync then calls Input.ReceiveAsync again without AdvanceTo having been called.

This would also have affected the upcoming UnixDomainSockets support. @birojnayak, make sure you rebase with this change before you test streamed mode transfer.

@mconnew mconnew merged commit 375ae8a into CoreWCF:main Jun 7, 2023
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants