在没有接收方的时候，一直发送数据包 <div class="highlight highlight-source-rust notranslate position

这里不太清楚为啥用异步 send ，UdpSocket的<code class="n

try_send 也挺好的，不知实现起来难不难🥲 <code clas

你可以加个超时，用 tokio::time::timeout 包在 <code class="notran

Client 端的 Session 只会在 KcpStream 实例析构时才会触发关闭逻辑 <p dir="a

send队列长度超过128时只阻塞不报错 about tokio_kcp HOT 7 OPEN

TheCGDF commented on August 15, 2024

send队列长度超过128时只阻塞不报错

from tokio_kcp.

Comments (7)

zonyitoo commented on August 15, 2024

这里不太清楚为啥用异步send，UdpSocket的send倒是同步的。

KCP的设计 send 就是异步的，真实IO只会在update和flush时才会产生。

发送第129个的时候send会阻塞住，而不是返回error，而且即便session的timeout到了也不会解除阻塞。

tokio_kcp/src/skcp.rs

Lines 148 to 167 in db5b613

 if self.sent_first 

 && (self.kcp.wait_snd() >= self.kcp.snd_wnd() as usize 

 || self.kcp.wait_snd() >= self.kcp.rmt_wnd() as usize 

 || self.kcp.waiting_conv()) 

 { 

 trace!( 

 "[SEND] waitsnd={} sndwnd={} rmtwnd={} excceeded or waiting conv={}", 

 self.kcp.wait_snd(), 

 self.kcp.snd_wnd(), 

 self.kcp.rmt_wnd(), 

 self.kcp.waiting_conv() 

 ); 

 if let Some(waker) = self.pending_sender.replace(cx.waker().clone()) { 

 if !cx.waker().will_wake(&waker) { 

 waker.wake(); 

 } 

 } 

 return Poll::Pending; 

 }

就是因为发送队列满了所以发不出去了。行为是合理的，用TCP如果对面一直不收，本地的socket buffer满了也是一样卡住。

是否可以考虑提供一个同步的send_sync函数？队列满了就直接返回报错。

那应该叫 try_send ，如果满了报错 EWOULDBLOCK

或者send在session超时后返回一个报错？

Client Stream 实际上根本不会超时，服务端的 Stream 才会有超时。Client 端的 Session 只会在 KcpStream 实例析构时才会触发关闭逻辑，会唤醒所有等待在 send 的 Task

如果可以的话还希望可以考虑下在KcpConfig里提供这个队列长度上限的配置。

可以试下

tokio_kcp/src/config.rs

Lines 68 to 69 in db5b613

 /// Send window size 

 pub wnd_size: (u16, u16),

from tokio_kcp.

TheCGDF commented on August 15, 2024

try_send也挺好的，不知实现起来难不难🥲

wnd_size试了不会影响队列的配置，我试了(256, 256)和(25600, 25600)，都是只能缓存128个

from tokio_kcp.

TheCGDF commented on August 15, 2024

Client Stream 实际上根本不会超时

这个之前确实不知道😢，因为用的另一个c#的kcp库的客户端倒是会超时，超时了send会报错🤯，导致我以为rust这边差不多

我以为超时了tokio_kcp的Client Stream也会自动关闭套接字。。。

from tokio_kcp.

zonyitoo commented on August 15, 2024

你可以加个超时，用 tokio::time::timeout 包在 send 调用上，这样就会超时了

from tokio_kcp.

TheCGDF commented on August 15, 2024

真实IO只会在update和flush时才会产生

我可能哪里没理解对，我知道只有update和flush时才会IO，所以我的理解send不是可以立即返回吗？send又没有等待update和flush？

from tokio_kcp.

zonyitoo commented on August 15, 2024

KCP的send 会不做任何限制地往snd_queue塞数据，最终会塞爆。因此在本项目如果已经积压超过上限，会主动等待。

from tokio_kcp.

TheCGDF commented on August 15, 2024

Client 端的 Session 只会在 KcpStream 实例析构时才会触发关闭逻辑

~~这个是不是会导致内存泄漏？~~

~~服务端每秒钟向客户端发送60个逻辑帧，每次客户端离线退出时，服务端的send队列会残留128个包。~~

~~而服务端的KcpStream是同一个一直运行着，不会产生析构，那是不是意味着这send队列里的包永远不会被释放？~~

~~我现在服务端这边内存泄漏非常严重，感觉会不会可能和这个有关系。。。。🤯🤯🤯~~

当我没说，一直运行着的是KcpSocket，KcpStream是会析构的，我再找找自己哪里搞出内存泄漏了。。。

from tokio_kcp.

send队列长度超过128时只阻塞不报错 about tokio_kcp HOT 7 OPEN

Comments (7)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	if self.sent_first
	&& (self.kcp.wait_snd() >= self.kcp.snd_wnd() as usize
	\|\| self.kcp.wait_snd() >= self.kcp.rmt_wnd() as usize
	\|\| self.kcp.waiting_conv())
	{
	trace!(
	"[SEND] waitsnd={} sndwnd={} rmtwnd={} excceeded or waiting conv={}",
	self.kcp.wait_snd(),
	self.kcp.snd_wnd(),
	self.kcp.rmt_wnd(),
	self.kcp.waiting_conv()
	);

	if let Some(waker) = self.pending_sender.replace(cx.waker().clone()) {
	if !cx.waker().will_wake(&waker) {
	waker.wake();
	}
	}
	return Poll::Pending;
	}