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.

Sign up for GitHub

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

Jump to bottom

[bug] when SO_LINGGER is used in the TCP half-closed scenario, the client in the fin_wait2 state cannot receive the data sent from the server which is in the close_wait state #11981

Closed
huibinliupush opened this issue Jan 8, 2022 · 0 comments
Closed

[bug] when SO_LINGGER is used in the TCP half-closed scenario, the client in the fin_wait2 state cannot receive the data sent from the server which is in the close_wait state #11981

huibinliupush opened this issue Jan 8, 2022 · 0 comments
Milestone
4.1.73.Final

Comments

@huibinliupush
Copy link
Contributor

SO_LINGERHalfClosureBug

as shown in the picture above。

when SO_LINGGER is used in the client side, and client call NioSocketChannel#shutdownOutput() to half close the tcp connection。

then server side OP_READ is active，server begin to shutdowninput and triger ChannelInputShutdownEvent，next send some data to client in the process handler of the ChannelInputShutdownEvent event。

Actual behavior

client in the FIN_WAIT2 state can not read and process these data which is sended by server in the CLOSE_WAIT state.

Expected behavior

client in the FIN_WAIT2 state can read and process these data which is sended by server in the CLOSE_WAIT state.

Steps to reproduce

 ServerBootstrap server = new ServerBootstrap();
 server.childOption(ChannelOption.ALLOW_HALF_CLOSURE, true)

 Bootstrap client = new Bootstrap();
 client.option(ChannelOption.SO_LINGER, 1)

Minimal yet complete reproducer code (or URL to code)

see unit test method testHalfClosureReceiveDataOnFinalWait2StateWhenSoLingerSet

Netty version

4.1.72.Final
@huibinliupush huibinliupush mentioned this issue Jan 8, 2022
Merged
normanmaurer added a commit that referenced this issue Jan 11, 2022
@huibinliupush @normanmaurer
ensure the side which enable SO_LINGER and call showdownOutput to sta…
d60ea59 
…rt TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state (#11982)

Motivation:

we can not call `doDeregister` to cancel the key of the channel from the selector in the `io.netty.channel.AbstractChannel.AbstractUnsafe#shutdownOutput(io.netty.channel.ChannelPromise, java.lang.Throwable)` method。

- because we should ensure the side which enbale `SO_LINGER` and call `showdownOutput` to start TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state。

- and the shutdown function does not block regardless of the SO_LINGER setting on the socket,so we don't need to use GlobalEventExecutor to execute the shutdown

Modification:

In summary there is no need to call `prepareToClose()` in the `AbstractChannel.AbstractUnsafe#shutdownOutput` method

Result:

Fixes issue #11981 

client in the FIN_WAIT2 state can read and process these data which is sended by server in the CLOSE_WAIT state，when SO_LINGGER is used in the TCP half-closed scenario

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
@normanmaurer normanmaurer added this to the 4.1.73.Final milestone Jan 11, 2022
normanmaurer added a commit that referenced this issue Jan 11, 2022
@huibinliupush @normanmaurer
ensure the side which enable SO_LINGER and call showdownOutput to sta…
927d04c 
…rt TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state (#11982)

Motivation:

we can not call `doDeregister` to cancel the key of the channel from the selector in the `io.netty.channel.AbstractChannel.AbstractUnsafe#shutdownOutput(io.netty.channel.ChannelPromise, java.lang.Throwable)` method。

- because we should ensure the side which enbale `SO_LINGER` and call `showdownOutput` to start TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state。

- and the shutdown function does not block regardless of the SO_LINGER setting on the socket,so we don't need to use GlobalEventExecutor to execute the shutdown

Modification:

In summary there is no need to call `prepareToClose()` in the `AbstractChannel.AbstractUnsafe#shutdownOutput` method

Result:

Fixes issue #11981

client in the FIN_WAIT2 state can read and process these data which is sended by server in the CLOSE_WAIT state，when SO_LINGGER is used in the TCP half-closed scenario

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
10brothers pushed a commit to 10brothers/netty that referenced this issue Jan 20, 2022
@huibinliupush @normanmaurer
ensure the side which enable SO_LINGER and call showdownOutput to sta…
e70dbf8 
…rt TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state (netty#11982)

Motivation:

we can not call `doDeregister` to cancel the key of the channel from the selector in the `io.netty.channel.AbstractChannel.AbstractUnsafe#shutdownOutput(io.netty.channel.ChannelPromise, java.lang.Throwable)` method。

- because we should ensure the side which enbale `SO_LINGER` and call `showdownOutput` to start TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state。

- and the shutdown function does not block regardless of the SO_LINGER setting on the socket,so we don't need to use GlobalEventExecutor to execute the shutdown

Modification:

In summary there is no need to call `prepareToClose()` in the `AbstractChannel.AbstractUnsafe#shutdownOutput` method

Result:

Fixes issue netty#11981 

client in the FIN_WAIT2 state can read and process these data which is sended by server in the CLOSE_WAIT state，when SO_LINGGER is used in the TCP half-closed scenario

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
raidyue pushed a commit to raidyue/netty that referenced this issue Jul 8, 2022
@huibinliupush @normanmaurer
ensure the side which enable SO_LINGER and call showdownOutput to sta…
b121fad 
…rt TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state (netty#11982)

Motivation:

we can not call `doDeregister` to cancel the key of the channel from the selector in the `io.netty.channel.AbstractChannel.AbstractUnsafe#shutdownOutput(io.netty.channel.ChannelPromise, java.lang.Throwable)` method。

- because we should ensure the side which enbale `SO_LINGER` and call `showdownOutput` to start TCP half-closure in fin_wait2 state can still receive and process the data which is send by another side in the close_wait state。

- and the shutdown function does not block regardless of the SO_LINGER setting on the socket,so we don't need to use GlobalEventExecutor to execute the shutdown

Modification:

In summary there is no need to call `prepareToClose()` in the `AbstractChannel.AbstractUnsafe#shutdownOutput` method

Result:

Fixes issue netty#11981 

client in the FIN_WAIT2 state can read and process these data which is sended by server in the CLOSE_WAIT state，when SO_LINGGER is used in the TCP half-closed scenario

Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
4.1.73.Final
Development

No branches or pull requests
2 participants
@normanmaurer @huibinliupush