Skip to content

English wiki for KCP #64

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

Open
winlinvip opened this issue Feb 15, 2017 · 17 comments
Open

English wiki for KCP #64

winlinvip opened this issue Feb 15, 2017 · 17 comments

Comments

@winlinvip
Copy link

winlinvip commented Feb 15, 2017

KCP is great. Sadly there is no English wiki, although my English is poor, but I want to make it.
I will try to translate the WIKIs to English, please correct me if any problem.

https://github.com/skywind3000/kcp/wiki/EN_Home

@skywind3000
Copy link
Owner

十分感谢,我会把入口加入到英文readme里面

@winlinvip
Copy link
Author

My pleasure~
有些专业词汇不会翻译,特别是:非退让流控,丢包退让。
找了下google貌似是大神你创造的,虽然中文是很好的隐喻,可惜不知道咋翻译,哈哈哈。

@winlinvip
Copy link
Author

winlinvip commented Feb 16, 2017

I plan to integrate KCP to SRS4, a live streaming cluster. I have filed a issue #770 for this.
Thanks for your awesome work~

@skywind3000
Copy link
Owner

skywind3000 commented Feb 16, 2017

我也不知道怎么叙述,所以我已经找有道翻译翻译了readme了,没准你可以拷贝一下
https://github.com/skywind3000/kcp/blob/master/README.en.md

@skywind3000
Copy link
Owner

还写了一个:
https://github.com/skywind3000/kcp/wiki/Success-Stories
的英文页面,时间不够,慢慢补充。

@winlinvip
Copy link
Author

大神,你不是已经有了English wiki了么?为啥不链接上呢?

@winlinvip
Copy link
Author

是因为直接粘贴全文到有道翻译的?确实有些地方翻译得不是很好理解。
不过我水平也不比有道高多少,哈哈哈。
话说这些词汇,譬如“非退让流控”,是中文就流行这么说是么?譬如老师就这么介绍的?如果是这样估计不好翻译,只能等专业英语更强的人纠正了。

@winlinvip
Copy link
Author

有人给我推荐了个TCP的相关术语:https://en.wikipedia.org/wiki/TCP_congestion_control

@skywind3000
Copy link
Owner

帖有道翻译翻译的能看么,有道人工翻译,专业技术翻译。

@skywind3000
Copy link
Owner

本来两天就翻译得出来,有道联系我说太难翻译了,要延期,最后第四天才拿给我的。

@winlinvip
Copy link
Author

大神,我的意思是如果这样的话,那其实有道翻译的就可以作为官方翻译了的,我就不翻译了的。

@winlinvip
Copy link
Author

https://github.com/skywind3000/kcp/wiki/EN_Home
我已经翻译完了。会参考有道的翻译再校正一遍。
再次感谢KCP,直觉会给流媒体带来很大的冲击。

@winlinvip
Copy link
Author

winlinvip commented Feb 20, 2017

https://github.com/skywind3000/kcp/blob/master/README.md#非退让流控
https://github.com/skywind3000/kcp/blob/master/README.en.md#non-concessional-flow-control

今天看了TCP的资料,退让流控,应该翻译成:Window Backoff Flow Control,有个论文就是叫《Congestion Avoidance and Control》,拥塞避免和控制。而TCP是通过窗口退让(Window backoff)实现。所以大神你说的这个非退让流控,实际上意思是:TCP基于退让窗口的流控达到避免拥塞的目的,而KCP使用非退让窗口达到弱网高效传输的目的。

所以我觉得应该直接翻译成流控: 退让或非退让(Flow Control: Window backoff or Not)
https://github.com/skywind3000/kcp/wiki/EN_KCP-Feature#flow-control

我还在看其他的TCP的资料,有不对的地方多多指正。

@winlinvip
Copy link
Author

winlinvip commented Feb 21, 2017

https://github.com/skywind3000/kcp/blob/master/README.md#技术特性
https://github.com/skywind3000/kcp/blob/master/README.en.md#technical-specifications
https://github.com/skywind3000/kcp/wiki/EN_KCP-Feature#algorithms

我校对了这一章,有一句话我觉得不应该直译,因为这个只是一个比喻而已,如果直接翻译反倒不好懂:

TCP信道是一条流速很慢,但每秒流量很大的大运河,而KCP是水流湍急的小激流。
TCP channel is a grand canal with very slow flow rate, but very large flow per second, while KCP is a small torrent with the rapid flow.

我觉得最好的做法就是不翻译,因为这句话只是对前面的内容的一个附加说明,去掉并不影响原意。前面已经说明的比较清楚了,加上反倒不好理解。

https://github.com/skywind3000/kcp/blob/master/README.md#rto翻倍vs不翻倍
https://github.com/skywind3000/kcp/blob/master/README.en.md#rto-doubled-vs-not-doubled
https://github.com/skywind3000/kcp/wiki/EN_KCP-Feature#exponential-backoff-or-not
这一段,看了下TCP的RTO的算法,大神你的意思RTO翻倍,应该是指“RTO指数退避”,也就是超时时RTO会翻倍。所以这一节我翻译成了指数退避。

有不对的地方请指出。😃

@winlinvip
Copy link
Author

winlinvip commented Feb 21, 2017

大神,我碰到个问题,查了相关资料没有说的很清楚的。希望你看到后能解答:

https://github.com/skywind3000/kcp/blob/master/README.md#选择性重传-vs-全部重传
TCP丢包时会全部重传从丢的那个包开始以后的数据,KCP是选择性重传,只重传真正丢失的数据包。

如何理解TCP会全部重传?“重传从丢的那个包开始以后的数据”是什么意思呢?譬如TCP发送包1,2,3,4,5,如果TCP快速重传收到三次2的ACK时,肯定是3丢失了,那TCP不是重传3,而是3+4+5都给重传了么?重传丢失的那个包,以及发送了没有收到ACK的包?是这个意思吗?还是?

在群里问了各路大神,应该是只会重传3,但是因为网络比较差,会导致后面丢包也不会立刻发现,特别是对于ACK丢失的情况(如果没有SACK),会导致陆续的重传,而且过程比较慢。
有大神说,可以改成这样:

kcp有更多的ack,在丢包情况下,可以更早的触发发送端的快速重传机制

@winlinvip
Copy link
Author

winlinvip commented Feb 21, 2017

https://github.com/skywind3000/kcp/blob/master/README.md#技术特性
https://github.com/skywind3000/kcp/blob/master/README.en.md#technical-specifications
https://github.com/skywind3000/kcp/wiki/EN_KCP-Feature

我已经校对完了这一节,主要改变的地方包括:

  1. packet改成了segmentpacket在IP层用得多,在传输层还是Segment比较常用。
  2. 对于UNA和ACK加了一个例子,请大神看我是不是理解对了。如果发送了1,2,3,4,5,收到了1,2,4,5,对于UNA会在收到4和5时回应3,因为丢失了3,发送端会重传3,4,5。而对于ACK则会回应1,2,4,5,开销比较大。而对于KCP,用UNA也就是回应1,2同时会有ACK=4,5这样可以判断是3丢失了。感觉有点点像SACK?https://github.com/skywind3000/kcp/wiki/EN_KCP-Feature#una-vs-ackuna
  3. 非退让流控,我的理解是TCP是比较悲观的,遇到丢几个包赶紧slow start,而KCP可以坚持比较快速丢包和重传,类似抢占式传输,获得比较高的效率,特别是丢包较严重的情况。

@winlinvip
Copy link
Author

其他两个文章也校对完了,Basic Usage有道有翻译,但是Best Practice没有,这两个因为专业词汇不多,所以校对差不多。我会学习一遍KCP的代码,再看看TCP的资料,然后再校对一遍。

https://github.com/skywind3000/kcp/wiki/EN_Home
大体上应该是差的不远了的。

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