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

UDPSession no longer flushes output queue on Close #273

Open
cohosh opened this issue Aug 27, 2024 · 3 comments
Open

UDPSession no longer flushes output queue on Close #273

cohosh opened this issue Aug 27, 2024 · 3 comments

Comments

@cohosh
Copy link

cohosh commented Aug 27, 2024

Ever since 651dc4a, a UDPSession will not flush queued outgoing packets when the connection is closed. Instead, there is a race condition in the select call of postProcess when the s.die channel is closed in Close:

		select {
		case buf := <-s.chPostProcessing: // dequeue from post processing

[snip]
			// notify chCork only when chPostProcessing is empty
			if len(s.chPostProcessing) == 0 {
				select {
				case chCork <- struct{}{}:
				default:
				}
			}
		case <-chCork: // emulate a corked socket
			if len(txqueue) > 0 {
				s.tx(txqueue)
				// recycle
				for k := range txqueue {
					xmitBuf.Put(txqueue[k].Buffers[0])
					txqueue[k].Buffers = nil
				}
				txqueue = txqueue[:0]
			}

		case <-s.die:
			return
		}

if Close is called immediately after a Write, the queued packets will not be sent. This wasn't an issue before because the uncork function was called from within Close.

I noticed this because one of our unit tests started failing when we tried to update the version of this library.

xtaci added a commit that referenced this issue Aug 28, 2024
@xtaci
Copy link
Owner

xtaci commented Aug 28, 2024

master...hotfix273
HI @cohosh, can you try this commit?

@xtaci xtaci closed this as completed in b15c0d1 Aug 28, 2024
@xtaci xtaci reopened this Aug 28, 2024
@cohosh
Copy link
Author

cohosh commented Aug 28, 2024

Thanks, that got rid of some of the race conditions but it looks like there are some remaining and our tests are still failing.

There's one in the output callback:

// delivery to post processing
select {
case sess.chPostProcessing <- bts:
case <-sess.die:
return
}

We could probably just remove the select statement here and always send the bytes to sess.chPostProcessing.

I just tried this locally but even with this fix there's still another problem where by the time the output callback sends to sess.chPostProcessing, the select statement in postProcess has already died because at the time, there wasn't anything in that channel.

@xtaci
Copy link
Owner

xtaci commented Aug 28, 2024

Thanks, that got rid of some of the race conditions but it looks like there are some remaining and our tests are still failing.

There's one in the output callback:

// delivery to post processing
select {
case sess.chPostProcessing <- bts:
case <-sess.die:
return
}

We could probably just remove the select statement here and always send the bytes to sess.chPostProcessing.

No,we can't do that, if chPostProcessing is full(because postProcess exits). It blocks forever on waiting for sending.

I just tried this locally but even with this fix there's still another problem where by the time the output callback sends to sess.chPostProcessing, the select statement in postProcess has already died because at the time, there wasn't anything in that channel.

Yup, The thing is a session cannot wait forever. So If 'Close()' is called, the session makes the 'best-effort delivery'.

tgragnato pushed a commit to tgragnato/snowflake that referenced this issue Sep 24, 2024
An update the the kcp-go library removes the guarantee that all data
written to a KCP connection will be flushed before the connection is
closed. Moving the sleep call has no impact on the integrity of the
tests, and gives the connection time to flush data before the connection
is closed.

See xtaci/kcp-go#273
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

No branches or pull requests

2 participants