某 v2er 做的 App 代码关键部分可能不是基于 LocalSend 改的

查看 44|回复 5
作者:othercat   
起因是看到 这个帖子 https:///t/1052120
然后我好奇做了一些事情 (之前用的图是 Dropbox 但是 V2EX 可能不支持,现在换成 imgur 的)
即把原作者 @LuLiangDev 的 Airclap v1.2.0 的 Frameworks 替换掉了 手头 v1.14.0 的 LocalSend

这样显示效果是被我吐槽是一个 Airclap v1.14.0

但是考虑到 Flutter 架构其实就是方便前端 UI 替换,所以根本考虑是否基于 LocalSend 修改还是要看行为
例如原作者 在 https:///t/1051102 提到
基于 SSDP 深度定制发现协议和 P2P 安全传输协议,利用多链路传输技术,保证数据不丢包, 安全稳定并且高速传输
所以和朋友一起研究了一下
首先先确保 LocalSend 的发现协议是基于 https://github.com/localsend/protocol 所说的私有协议
The default multicast group is 224.0.0.0/24 because some Android devices reject any other multicast group.
Multicast (UDP)
    Port: 53317
    Address: 224.0.0.167
那么通过 WireShark 抓包的确能看到是这样的

那么我们替换之后的新 Airclap v1.2.0 到底是和 LocalSend 一致,还是和作者所说的一致呢?
通过抓包发现

因为 SSDP 一般使用多播地址 239.255.255.250 和 UDP 端口号 1900 ,所以可以认为作者说的符合他自己的描述
后续就不用特别研究了,因为至少目前为止,Airclap 表现的行为,和作者在发布的描述是一致的,而且的确是和 LocalSend 区别很大的
所以可以认为,@LuLiangDev 的 Airclap ,代码关键部分可能不是基于 LocalSend 改的。
以上。
Goooooos   
人们更愿意相信自己认为的,所以你这贴没啥用,只有作者完全开放源代码,就像电影《让子弹飞》里的老六为了证明自己只吃了一碗凉粉。
但作为一个付费 APP ,作者肯定不会开放源码。
othercat
OP
  
@Goooooos 所以我只是说关键代码不是基于 LocalSend 修改,因为协议层实现比 UI 还是要复杂得多(当然不一定比 LocalSend 更优雅或者安全)
我相信通过替换 Framework 可以直接使用,应该是有借鉴 Flutter 层面相关代码的,但是由于关键功能的协议层自己有实现,因此作者认为自己没有抄袭可能也有他自己的道理。
w568w   
大家关心的问题不在于「抄没抄」,而是「遵没遵守协议」。不要打烟雾弹。
LocalSend 使用的 MIT 协议本来就是允许抄、欢迎抄的。退一万步说,就算他抄了,抄袭不可耻,闭源也不可耻,盈利更没有违反任何协议,完全是他的营销本事。
现在的关键是:他是否基于 LocalSend 代码二次开发,以及是否履行 MIT 协议。
其项目源代码结构被逆向工程发现和 LocalSend 的目录结构、文件名完全一致,这基本确定是基于 LocalSend 源代码。然而其三番五次声称自己和 LocalSend 「没有任何关系」,也没有看到任何协议标注和版权署名,这才是问题所在。
至于核心代码如何变化,我想这并非目前的重点。SSDP Flutter 方面的库也很多很成熟了,LocalSend 的 Provider 架构写得很好,加个协议只是复制粘贴的时间。
w568w   
@w568w 注:第一句没有说楼主故意混淆视听的意思。
othercat
OP
  
@w568w 没有打烟雾弹,只是描述一个事实。因为 Flutter UI 实在太好替换和借鉴,而 LocalSend 的代码结构说实话因为写的太规范,所以也可以认为有规范的人都可以写的相似。
目录结构现在我只看到大家借鉴的是主程序部分,但是主程序说老实话,只有 UI ,因为协议层都不在这里。
因此这部分我仔细看了一下引用的几个核心网络层面 Framework 的实现,其实有很多和 LocalSend 引用的不同,当然因为闭源很难证明,我也没精力和兴趣去证明。
我只想表达,协议层面自己造轮子实现,如果用 LocalSend 的代码二次开发,可能会更痛苦。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部