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

关于 gnet 代码的问题 #3

Closed
Allenxuxu opened this issue Oct 29, 2019 · 10 comments
Closed

关于 gnet 代码的问题 #3

Allenxuxu opened this issue Oct 29, 2019 · 10 comments
Assignees
Labels
invalid This doesn't seem right 开源碰瓷

Comments

@Allenxuxu
Copy link

借鉴不加以说明,就是抄袭

前期 gnet 就是从 eviop copy 过来改的,当时文件名称都一样。 之前我也提了 issue ,你说只借鉴了 ringbuffer ,火速关了 issue,说要加上说明。panjf2000/gnet#1

现在说明呢?


gev 项目创建日期,远早于 gnet ,从提交记录时间可以看出。如果你从 gev 有“借鉴”之处,还请附上说明。

我用 options 做默认配置,你也用。
https://github.com/panjf2000/gnet/blob/master/options.go
https://github.com/Allenxuxu/gev/blob/master/options.go

我前两天刚给 ringbuffer 加 pool,你今天也加。
Allenxuxu/ringbuffer@1048a07
panjf2000/gnet@998b920

如果去看代码,相似之处非常多。

@panjf2000 panjf2000 changed the title 借鉴不加以说明,就是抄袭! 关于 gnet 的问题 Oct 29, 2019
@panjf2000
Copy link
Member

panjf2000 commented Oct 29, 2019

第一,最早只是 eviop 里的 ringbuffer 这个思路启发了我做了 gnet,你也是参考这个库: ringbuffer 实现的,我自己做了一些优化重构,所以三方的版权信息我都加了,而这个的版权信息从最早提交代码之时就已经声明:https://github.com/panjf2000/gnet/blob/master/ringbuffer/ring_buffer.go#L3, 且一直保留着,同样的,很早的时候我已经加了 eviop 鸣谢:42211b2,你自己不看怪谁?而且你少给我在这颠倒黑白,当时我是先补充了 eviop 的致谢在 README 上,提交了 commit,然后去 issue 里回复你说已经更新好 README,最后才关掉了 issue,什么叫火速关了 issue?当别人看不到 issue 的 logs 吗?况且,当时发布 gnet 时候,它的核心部分:网络模型就已经是完全重新设计成 Multi-Reactors 模式的了,和 eviop 完全不同,而你的 eviop 除了引入 ringbuffer 和做了一些小优化,其余部分完全照搬了evio 的架构和代码,包括核心的网络模型。另外,我很早的时候(今年4月份)就已经在关注 evio 了,也提交过 PRs, 只不过和作者有分歧才没有合入,之后我就一直在思考把 evio 改造成 Reactor 模型的工作,gnet 发布的时候整个网络模型就和 evio 和 eviop 是完全不同的,但是毕竟是 evio 启发了我做 gnet,因此我从一开始就在 gnet 的开源证书里给 evio 的作者署名了:gnet 开源证书,倒是你的 gev 可从来没有在开源证书里加上 evio 作者的名字呢!后来你提出在 gnet 的 README 加上对 eviop 的致谢,而事实上在 gnet 的小部分代码里我已经加上了你的名字了,于情于理我本来都可以拒绝,但是我想着做个好人,最后还是在 README 加上了,真是没想到现在还被你这无赖反噬了,只能说讽刺啊!

再后来,gnet 持续迭代和开发,我开始认真整理项目代码和文档,经过考虑,eviop 对 gnet 有一定的启发作用,但是微乎其微,最主要的还是 evio 这个项目,故而从 README 移除 eviop(不过 ringbuffer 的 MIT 证书版权声明我一直留着你的名字,告诉你别给继续我撒泼耍无赖,真给我气急了我这里就删掉你的名字),只保留二者最初共同的参考项目: evio 的致谢,因为用 Go 实现 event-driven 网络库的 idea 主要是 evio 作者的贡献,不管是 gnet、eviop 还是 gev 都是衍生自 evio。

第二,关于 functional options 的概念,最早是由 go 创始人 Rob Pike 提出来的: https://commandcenter.blogspot.com/2014/01/self-referential-functions-and-design.html, 而且这种模式在很多流行的 go 开源库都在使用,又不是只有你一个人知道这个概念,什么时候变成你的专利了?再说了,我以前的项目也用过 functional options,https://github.com/panjf2000/ants/blob/master/ants.go#L86, 时间比你的 gev 早得多了,那我现在反问你,是不是抄袭了我的代码?引入 functional options 是因为很早之前有一位同学给我提了 issue: panjf2000/gnet#20,我就开始考虑后面加入一些新配置的向后兼容性问题,又因为之前我的另一个项目 panjf2000/ants@201ac20 曾经通过引入 functional options 解决了向后兼容性的问题,所以我就用了 functional options,时间同样比你早,而且引入 functional options 这是很多 golang 库的常规做法,和你的项目没有任何关系。

第三,关于 ringbuffer 池化,最早是由一位同学给 gnet 提了 issue,建议在 gnet 里加连接池,避免每次新建连接都创建 conn struct 进而做两次 ringbuffer 内存分配,在这里: panjf2000/gnet#27, 我当时第一时间就在下面留了 comment, 给出了用 sync.Pool 来做池化的思路,那是九天前,我九天前就把使用 sync.Pool 来做池化的思路写在 issue 里然后因为个人时间的关系没有马上去做,但是最后的实际代码提交也比你早,我是10月25号中午 12:40 提交的 commit 4cc2f96:
image
而你对应的 commit 1048a0 是在10月25号晚上 19:36 才提交的:
image

,然后你说我抄了你的代码?到底谁抄谁?我怎么抄?穿越吗?我还没质疑是你 "借鉴" 了我的代码呢!结果你来个倒打一耙?脸皮可真够厚的!后来是因为有另一位同学,给我反馈了这个新特性(复用 conn)在 『Reactors + goroutine pool』的模式下的 bug: panjf2000/gnet#29 ,我才稍微修改了一下,在之前池化整个 conn 的代码基础上改成了只池化 conn 里面的 ringbuffer,连代码的基本结构都没变,且思路和效果是一样的,都是为了减少 ringbuffer 的内存分配,所以这个也和你的项目没有任何关系。

@Allenxuxu
Copy link
Author

第一点,ringbuffer 你重构了个啥?
关于第二点, functional options 我没有说是我的专利。只是为了说明,gnet 和 gev 有太多相似的地方了, 而 gev 的提交时间远早于 gnet 。
第三点,你别混淆视听,连接池和 ringbuf pool 是一个东西吗。

我也不想过多争论,借鉴之处简单说明一下不就 ok 了吗?
你急着 关闭 issue 干嘛?

@panjf2000
Copy link
Member

panjf2000 commented Oct 29, 2019

你的 gev 说是借鉴了 muduo,而 muduo 也有不少实现是参考自 netty,这些基于事件驱动的网络框架的很多设计优化思路是大同小异的,比如 netty 里也有个类似的链接 buffer 池,难道也是抄你的?gnet 里面的很多优化我也是从 netty 的源码里得到的启发,而你说的两者有一些相似的地方,我看了一下你很多代码就是直接从 muduo 移植过来的,而在 netty 里也有类似的代码,我不清楚是 muduo 还是 netty 更早写的,但是我的 gnet 有很多优化的确是参考自 netty。

所以,我没时间也没兴趣去 "借鉴" 你的 gev,我有那时间继续钻研 netty 不好吗?

@panjf2000
Copy link
Member

panjf2000 commented Oct 29, 2019

你急着 关闭 issue 干嘛?

你这无赖跑到我家门口泼屎,我难道还要好吃好喝伺候着你?抱歉,我可不是什么以德报怨的人,这种垃圾 issue 我见一个关一个!自己不看清楚 github 提交记录的时间,一上来就毫无根据地扣一顶抄袭的帽子,你这是讨论问题的态度吗?连最基本的素质都没有!你就觉得其他人都是在抄袭你?我就没见过像你这么不要脸自以为是的人!

你提出的那些质疑,我都一一驳斥了,那些相关的功能我都说明了:最早是其他用户给我提了 issue (所有相关 issues 也在前面列出来了),我觉得有价值才实现了那些功能,而且我的 commits 时间都比你相应的那些 commits 更早, 所以你说我"借鉴"了你的代码完全是血口喷人和贼喊捉贼,我现在还怀疑是你"借鉴"了我的代码呢!issue 是用来合理反馈问题的,不是用来造谣的,所以我还开着这个 issue 干嘛?

你要是想讨论问题,我随时欢迎,你可以重新开一个 issue,我们当然可以讨论,但是这个 issue 从一开始你就不是冲着讨论问题来的,我前面也贴了我的 commits,提交时间都比你更早,但我有跑到你的项目下面嚷嚷着说你抄袭吗?所以我为什么不能关掉这种毫无根据的指责?难道开着让它污染我的 issue 列表?

我也不想过多争论,借鉴之处简单说明一下不就 ok 了吗?

evio、netty、pool 这些我或借鉴或使用的库我都在 README 以及 LICENSE 里加了版权声明/使用说明,eviop 的 ringbuffer 版权信息更是在最早提交 gnet 代码之初到现在一直保留着。
我要是借鉴了肯定会写上,但要是本来就没有所谓的"借鉴",我凭什么要加什么说明?搞笑!

@panjf2000
Copy link
Member

panjf2000 commented Oct 29, 2019

第一点,ringbuffer 你重构了个啥?

要不要到医院挂个眼科?自己不会看 git diff?

关于第二点, functional options 我没有说是我的专利。只是为了说明,gnet 和 gev 有太多相似的地方了, 而 gev 的提交时间远早于 gnet 。

你自己都承认了这两个项目最早都是衍生自 evio,可不就会有些代码逻辑相似吗?而且,你的很多代码是直接从 muduo 搬过来的,而 muduo 和 netty 有很多类似的思想,你能参考 muduo ,我就不能参考 netty?你是不是觉得某个概念、思路你用在项目里了,然后看到别人也有,就是抄袭你?且不说 gnet 的一些相关 commits 提交时间比 gev 更早,况且很多优化思路你都是从 muduo 直接拿过来用的,netty 里同样也有相似的代码,怎么,你是不是也想去 netty 那里说他们抄袭了你?你不出生在韩国真是可惜了。

我从来没有否认过 gnet 最早借鉴了 eviop 里面的 ringbuffer 思路,关于这个我已经说过好几次了,ringbuffer 相关的 copyright 我从提交 gnet 代码的第一天就已经加上了,另外,从一开始二者最核心的网络模型和架构就是完全不同的,gnet 是全新的,之后也已经脱离了 evio 和 eviop 的模式。至于 gev,我只能说 gnet 和它没半毛钱关系。

第三点,你别混淆视听,连接池和 ringbuf pool 是一个东西吗。

你别装傻充愣,我看了一下你的那个 commit,你那个所谓的 ringbuffer pool 不也是用 sync.Pool 缓存 ringbuffer 吗?我那个 commit 也已经在前面贴出来了,提交时间比你早,一开始我是池化整个 conn struct,主要目的是为了池化 conn 里面的 ringbuffer,但是后来发现复用 conn 在『Reactors + goroutine pool』的模式下有 bug: panjf2000/gnet#29 ,所以就在之前的代码基础上修改了一下,只池化 conn 里面的 ringbuffer,还是沿用了之前代码基本的结构,思路和效果还是一样的,都是为了减少 ringbuffer 的内存分配,我九天前就把使用 sync.Pool 来做池化的思路写 issue panjf2000/gnet#27 里了,然后因为个人时间的问题没有马上完成,但是最后代码提交的时间也比你更早,我是在 10月25号中午 12:40 提交的commit 4cc2f96 而你的对应 commit 1048a0 是在四天前的10月25号晚上 19:36 才提交的,然后你说是我借鉴了你的代码?谁给的你勇气?梁静茹吗?

@Allenxuxu
Copy link
Author

争论没有任何意义。
我只是来表达不爽:我增加啥,你就增加啥?
既然你认为是巧合,我相信提交记录时间都有,也没啥争论的必要。

@panjf2000
Copy link
Member

panjf2000 commented Oct 29, 2019

你不爽?我平白无故被扣一顶抄袭的帽子,我才应该不爽好吧!

我只是来表达不爽:我增加啥,你就增加啥?

我无语了,要论证谁先谁后,不就是看 commits 时间吗?我前面已经把所有你提到的所有相似功能的对应 commits 时间都贴出来了,结果就是,我提交的时间都比你早,你哪来的脸还在这说是你先加我后加?

就拿你这个 commit 来说:Allenxuxu/gev@e64d6e2, 你用了 github.com/gobwas/pool/pbytes 这个库,而 gnet 从一开始就是用它来做内存池了,你后来也加了这个功能,我现在问你,是不是抄了我的代码?

@Allenxuxu
Copy link
Author

Allenxuxu commented Oct 29, 2019

就拿你这个 commit 来说:Allenxuxu/gev@e64d6e2, 你用了 github.com/gobwas/pool/pbytes 这个库,而 gnet 从一开始就是用它来做内存池了,你现在加是不是巧合?我不会觉得是你 "借鉴" 了我,因为我前面说了,很多优化思路是相似的,做内存优化 ——> 用内存池 ——> 上 github 搜相关的 library ——> 找到合适的 library ——> 用到自己的项目里,现在你不就和我用了同一个库来做内存池吗?

我在使用 gobwas 的 ws 库增加 websocket 特性的时候,就已经看到 github.com/gobwas/pool/pbytes ,并非借鉴你。


先不说 eviop,我就说我后来的 gev。

我在 9 月 1 号, gev 第一次提交,就已经有了 ringbuffer + reactor 网络模型的优化方式: Allenxuxu/gev@99af947

而 gnet 9 月 15 号才创建,你说你比我早?

@panjf2000
Copy link
Member

panjf2000 commented Oct 29, 2019

我真是服了你了,除了眼科我觉得你还需要顺便去脑科也看一看。。。我啥时候说 gnet 的创建时间更早了?我哪句话提到了项目的创建时间?我说的是前面你提到的那些 commits,提交时间都是我更早!!!

至于 Multi-Reactors ,本来就是一个经典的网络模型,几乎所有流行的开源网络库都用的是这个模型,netty、libuv、libevent 和 muduo 等等,所以这种网络模型的实现方案已经非常成熟了,核心逻辑都是一致的,我要用 Go 来实现这个模型,就算要参考,我也只会去参考 netty、libuv 这些更优秀的开源实现,有必要去参考你的个人项目 - gev?况且你那个 gev 也是参考自 muduo,我刚才去看了下,基本就是把 muduo 的语言从 C++ 改成了 Go,这也能拿来吹嘘?

最早是我在无意间看到了 eviop 这个项目,通过引入了 ringbuffer 完善了 evio 本身简陋的 buffer 功能,我觉得是个不错的思路,然后就基于此重新设计了 Multi-Reactors 的网络模型,进而新开发了 gnet,根本不知道有 gev,而你是在我发布 gnet 并在网上发博客推广之后的一段时间才学着我那样去推广 gev 的,在此之前我根本不知道有 gev 这个东西,我也是后来看到你在网上发的推广才知道有这个项目。我这么说吧,也就是 gnet 现在收获了这么多 stars 你才会跑我这里来毫无根据地找茬,如果 gnet 这项目没什么人关注的话,我猜你会很安静。

至于我和 evio 渊源,在很早的时候(今年4月份)我就已经在关注 evio 了,也提交过 PRs, 只不过和作者有分歧才没有合入,之后我就一直在考虑把 evio 改造成 Reactors 模型的事了,最早发布 gnet 代码之时它的核心部分:网络模型就已经是完全重新设计的了,和 eviop 完全不同。至于 gev,我最后再说一遍,我的 gnet 从盘古开天辟地到宇宙毁灭都和你以及你的 gev 没有半毛钱关系!!!

有时间在跑到我这里来碰瓷,不如好好做你的开源库,奉劝你一句:少出来哗众取宠!

@Allenxuxu
Copy link
Author

Allenxuxu commented Oct 29, 2019

没啥争论的必要,各搞各的的就行了。

@panjf2000 panjf2000 transferred this issue from panjf2000/gnet Nov 1, 2019
@panjf2000 panjf2000 changed the title 关于 gnet 的问题 关于 gnet 版权的问题 Jul 5, 2020
@gnet-io gnet-io locked as spam and limited conversation to collaborators Jul 5, 2020
@panjf2000 panjf2000 added the invalid This doesn't seem right label Jul 5, 2020
@panjf2000 panjf2000 changed the title 关于 gnet 版权的问题 关于 gnet 代码的问题 Jul 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
invalid This doesn't seem right 开源碰瓷
Projects
None yet
Development

No branches or pull requests

2 participants