Skip to content

Conversation

@rstoyanchev
Copy link
Contributor

In b15a1fc transports started applying FragmentationDuplexConnection. This was probably done so that TCP transports can give up control of dealing with the frame length to the fragmentation layer. However on closer look there is no obvious reason to not leave the frame length to transports to deal with.

The two commits here restore fragmentation being applied from a single place and make transports unaware of that logic eliminating duplication in the process.

@rstoyanchev rstoyanchev added the refactorings Changes that does not affect API and behaviour label May 15, 2020
@rstoyanchev rstoyanchev added this to the 1.0.1 milestone May 15, 2020
@rstoyanchev rstoyanchev force-pushed the fragmentation-refactor branch 2 times, most recently from 7f2510a to c3daf03 Compare May 15, 2020 12:43
Copy link
Member

@OlegDokuka OlegDokuka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in general. Few comments to consider

@rstoyanchev rstoyanchev force-pushed the fragmentation-refactor branch from c3daf03 to 8817dac Compare May 15, 2020 13:19
@rstoyanchev
Copy link
Contributor Author

I've cleaned up further as suggested.

The flags were introduced in rsocket#585 such that when fragmentation is
enabled, it takes over the encoding and decoding of the frame length
instead of the underlying transport.

However this doesn't seem to have any obvious purpose. On the sending
side, fragmentation breaks down the frames and then the transport can
add the length just as well. On the receiving side, the transport is
first anyway.

It's better to simplify this and leave it to transports to decide this
whether a length is needed and expected.

Signed-off-by: Rossen Stoyanchev <[email protected]>
The flag was added in b15a1f so transports can decorate with a
FragmentationDuplexConnection but the logic is the same everywhere and
can be applied from a single place without the transport having to know
about it.

Signed-off-by: Rossen Stoyanchev <[email protected]>
@rstoyanchev rstoyanchev force-pushed the fragmentation-refactor branch from 8817dac to 207e684 Compare May 15, 2020 13:38
@OlegDokuka OlegDokuka merged commit d8da87a into rsocket:master May 15, 2020
@rstoyanchev rstoyanchev deleted the fragmentation-refactor branch May 15, 2020 15:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactorings Changes that does not affect API and behaviour

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants