Frame reassembly application logic is insufficient

[mostroverkhov]

FrameReassembler connection is applied only if mtu>0, but reassembly should always happen for incoming frames, and mtu must be used for outgoing frames

[nebhale]

I’ll take a look at this today.

[nebhale]

What would be your expected behavior be if you attempted to apply the FragmentationDuplexConnection with a negative number? At the moment it throws an exception preventing startup completely, but I get the sense that you'd like a different behavior. Would you expect fragmentation to simply not happen but allow startup to proceed with reassembly?

More generally, what does the matrix of negative/zero/positive crossed with fragmentation/reassembly look like?

[mostroverkhov]

My concern is reassembly is happening conditionally - if one side of connection has mtu = 0, it cant reassemble frames, coming from other side. Reassembly is not negotiated on setup, so any peer can send disassembled frames any time. Hence FragmentationDuplexConnection must always be used.

[nebhale]

OK, so the main concern is an MTU of 0, not a negative MTU? The comment updates makes this clear now. I'll have a patch to support this.

[mostroverkhov]

This gets applied conditionally. Having one peer mtu=0 and other e.g mtu =5 leads to situation when peers cant talk to each other for frames of size e.g. 100. Hope this helps.

[nebhale]

Yep, that definitely helps and I'm on the trail now. Did this work in before 0.11.0? I'm going over the code for 0.10.3 and don't see any special cases (just looking to replicate any existing behavior before inventing my own).

[mostroverkhov]

I suspect It is there from the beginning :). Working now on another rsocket implementation - so this is one of ton of issues I find comparing this implementation with spec.

[nebhale]

Understood. Thank for the quick responses. I'm working on a PR now.