Is data in a datapipe discarded if reset is called?

[Marten Richter]

Hi,

I am trying to investigate the following chromium issue:

Closing a WebTransport stream can cause unsent messages to be dropped [326887753] - Issue Tracker (google.com)

My investigation showed that the last data sent seems lost if the data pipe is closed with a call to reset on the producer side.

As I do not entirely understand what happens when reset is called on a data pipe (I have seen that a box is set to empty on the producer side), I wonder if this discards the data currently being transferred and not yet read by the consumer.

If this is the case, another communication channel must be implemented for web transport.
But if that is not the case, I would like to know what the code does wrong so that the last data bytes are not transferred.

(Here are some other involved code parts:

https://source.chromium.org/chromium/chromium/src/+/main:services/network/web_transport.cc;drc=4b37c48511e47ec895e68de92bd8e519f25a1264;l=242

The data is lost here:
https://source.chromium.org/chromium/chromium/src/+/main:services/network/web_transport.cc;drc=4b37c48511e47ec895e68de92bd8e519f25a1264;l=253

May be, it is possible to read the remaining data also in this case?

)

Thanks!

Marten

[Ken Rockot]

On Tuesday, August 27, 2024 at 7:05:42 AM UTC-7 marten.m...@googlemail.com wrote:

Hi,

I am trying to investigate the following chromium issue:

Closing a WebTransport stream can cause unsent messages to be dropped [326887753] - Issue Tracker (google.com)

My investigation showed that the last data sent seems lost if the data pipe is closed with a call to reset on the producer side.

As I do not entirely understand what happens when reset is called on a data pipe (I have seen that a box is set to empty on the producer side), I wonder if this discards the data currently being transferred and not yet read by the consumer.

No, that's not the intended behavior. All written data should be readable by the consumer even if it was written immediately before closing the producer.

 

If this is the case, another communication channel must be implemented for web transport.
But if that is not the case, I would like to know what the code does wrong so that the last data bytes are not transferred.

(Here are some other involved code parts:

https://source.chromium.org/chromium/chromium/src/+/main:services/network/web_transport.cc;drc=4b37c48511e47ec895e68de92bd8e519f25a1264;l=242

The data is lost here:
https://source.chromium.org/chromium/chromium/src/+/main:services/network/web_transport.cc;drc=4b37c48511e47ec895e68de92bd8e519f25a1264;l=253

May be, it is possible to read the remaining data also in this case?

)

Do you have a reduced test case which demonstrates the broken behavior?

 

Thanks!

Marten

[Marten Richter]

Okay, that's good to know. Either I misinterpreted the debugging, or it is a bug in the Datapipe.

Regarding the minimal example, you may either use the steps described by achingbrain in the first post in the bug:
"

1. Start a WebTransport echo server - e.g. https://github.com/achingbrain/webtransport-echo-server
2. Copy/paste the transport variable setup code into this demo - https://codepen.io/achingbrain/pen/eYXqyYP
3. See the number of received chunks reported in the console"

or I can send you instructions on using my debug setup, which is a bit more debug-friendly.
But all of these involve a webtransport server, a simple code just using the ipc calls I do not have, as I am trying to understand how the ipc functions.

What I did to identify the problem, I have counted the written bytes in (consumer side):

https://source.chromium.org/chromium/chromium/src/+/main:services/network/web_transport.cc;drc=4b37c48511e47ec895e68de92bd8e519f25a1264;l=242

and compared them against the known value of 1024*1024

https://source.chromium.org/chromium/chromium/src/+/main:services/network/web_transport.cc;drc=4b37c48511e47ec895e68de92bd8e519f25a1264;l=281

I also count on the producer side here:

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webtransport/outgoing_stream.cc;drc=44a6971702ccf11e29f5582703c8726be6eefab2;l=438

and compare

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/webtransport/outgoing_stream.cc;drc=44a6971702ccf11e29f5582703c8726be6eefab2;l=114

with the correct value here. The result is that all bytes are written to the pipe, and not all bytes are received on the consumer side.

Please note: I am just someone who writes a node.js web transport plugin and occasionally fixes bugs related to web transport in browsers. So, my knowledge about the internals of Chrome (and mojo in particular) is limited.