litebook资源分享系统

[LiteBook.Author]

这是我一直想做的一个功能，目的是在litebook用户间建造一个图书共享网络。
实现这个功能有很多种技术选择，但是考虑到扩展性的话，基本上剩下两种P2P网络：
- 集中式：在这个模式里，有一个（或多个）中央服务器作为目录服务器；每个客户端将自己共享的文件名列表上传到中央服务器并提供相应文件的下载服务。
客户端可以到服务器上查询想要的文件（按文件名），服务器就会返回相应共享客户端的URL，然后客户端直接从共享客户端下载。
- 全分布式：在这个模式中，没有中央服务器，采用类似DHT式分布式哈希表技术，共享文件的注册和将针对文件名的查询都被哈希到不同的客户端执行。

这两种模式相比较的话，显然全分布式的扩展性和隐私性更好，但是实现起来复杂，而且如果网络客户端数量少的，其查找的效率是很低的。集中式实现起来简
单，但是需要用到中央服务器，可能会带来一定的成本...

看看大家还有什么好办法?

[Chunlin Zhang]

纯p2p估计比较不可靠吧,感觉还是混合式比较好,只有最开始一次或者比较少数的情况下依赖于关键服务器节点,这样能够获得比较多的节点信息,其余情况依赖于其他节点.对 p2p 了解不多上面这些比较多是猜的.

不过做这个容易碰到版权问题...

[Zoom.Quiet]

在 2011年4月13日 上午11:42，LiteBook.Author <liteboo...@gmail.com> 写道：
> 这是我一直想做的一个功能，目的是在litebook用户间建造一个图书共享网络。

- 伟大的理想!!!!
- 不过,得和相关版权内容商有一战,得留好后路...

> 实现这个功能有很多种技术选择，但是考虑到扩展性的话，基本上剩下两种P2P网络：
> - 集中式：在这个模式里，有一个（或多个）中央服务器作为目录服务器；每个客户端将自己共享的文件名列表上传到中央服务器并提供相应文件的下载服务。
> 客户端可以到服务器上查询想要的文件（按文件名），服务器就会返回相应共享客户端的URL，然后客户端直接从共享客户端下载。
> - 全分布式：在这个模式中，没有中央服务器，采用类似DHT式分布式哈希表技术，共享文件的注册和将针对文件名的查询都被哈希到不同的客户端执行。
>
> 这两种模式相比较的话，显然全分布式的扩展性和隐私性更好，但是实现起来复杂，而且如果网络客户端数量少的，其查找的效率是很低的。集中式实现起来简
> 单，但是需要用到中央服务器，可能会带来一定的成本...

建议哪,根据国情来...
+ 初期,不知道有多少 LB2 客户端的情况下,先使用集中式:
- 开发简单
- 中央服务压力也少
- 便于收集,观察 LB2 使用情况
+ 中期,部分稳定客户端开启 p2p 服务
- 进行简单的 多服务 尝试,以及p2p 的技术积累
- 给予这类客户端特殊地位
- 加强 p2p 的体验,吸引更多的人...
+ 俺设想,起点的作家们如果使用 LB2 来快速查阅自个儿喜欢的作品
+ 并可以就地评注,并自动分享给对应作家
...咔咔咔!
+ 后期,完全 p2p 让有关部门找不到北,只能封锁 code.google 了事儿..

--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
哲: http://www.zeuux.org/home/zoomquiet
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
营: http://code.google.com/p/kcpycamp/wiki/PythoniCamp

[马剑]

建议做平台工具，去搜书。

如果提供内容的话，很快就会翘辫子的。

在 2011年4月13日 上午11:42，LiteBook.Author <liteboo...@gmail.com>写道：

--
邮件来自: litebook ~ "轻巧看书"讨论列表
发言: lite...@googlegroups.com
退订: litebook+u...@googlegroups.com
详情: https://groups.google.com/group/litebook
开发: http://code.google.com/p/litebook-project/

[Zoom.Quiet]

在 2011年4月14日 上午9:36，马剑 <honey...@gmail.com> 写道：
> 建议做平台工具，去搜书。
> 如果提供内容的话，很快就会翘辫子的。
>
- 嗯嗯嗯,至少进行分支吧 LB3 作这种包含分享的

> 在 2011年4月13日 上午11:42，LiteBook.Author <liteboo...@gmail.com>写道：
>>
>> 这是我一直想做的一个功能，目的是在litebook用户间建造一个图书共享网络。
>> 实现这个功能有很多种技术选择，但是考虑到扩展性的话，基本上剩下两种P2P网络：
>> - 集中式：在这个模式里，有一个（或多个）中央服务器作为目录服务器；每个客户端将自己共享的文件名列表上传到中央服务器并提供相应文件的下载服务。
>> 客户端可以到服务器上查询想要的文件（按文件名），服务器就会返回相应共享客户端的URL，然后客户端直接从共享客户端下载。
>> - 全分布式：在这个模式中，没有中央服务器，采用类似DHT式分布式哈希表技术，共享文件的注册和将针对文件名的查询都被哈希到不同的客户端执行。
>>
>> 这两种模式相比较的话，显然全分布式的扩展性和隐私性更好，但是实现起来复杂，而且如果网络客户端数量少的，其查找的效率是很低的。集中式实现起来简
>> 单，但是需要用到中央服务器，可能会带来一定的成本...

--

[LiteBook.Author]

On Apr 13, 6:36 pm, 马剑 <honeyday...@gmail.com> wrote:
> 建议做平台工具，去搜书。
> 如果提供内容的话，很快就会翘辫子的。

服务器上不提供内容，仅提供搜索服务，下载是从客户端到客户端，这样也有问题？

[Zoom.Quiet]

在 2011年4月14日 上午11:16，LiteBook.Author <liteboo...@gmail.com> 写道：
> On Apr 13, 6:36 pm, 马剑 <honeyday...@gmail.com> wrote:
>> 建议做平台工具，去搜书。
>> 如果提供内容的话，很快就会翘辫子的。
>
> 服务器上不提供内容，仅提供搜索服务，下载是从客户端到客户端，这样也有问题？
>

- KAO！ 海盗湾不就是这么倒的！？
...

>> > 这是我一直想做的一个功能，目的是在litebook用户间建造一个图书共享网络。
>> > 实现这个功能有很多种技术选择，但是考虑到扩展性的话，基本上剩下两种P2P网络：
>> > - 集中式：在这个模式里，有一个（或多个）中央服务器作为目录服务器；每个客户端将自己共享的文件名列表上传到中央服务器并提供相应文件的下载服务。
>> > 客户端可以到服务器上查询想要的文件（按文件名），服务器就会返回相应共享客户端的URL，然后客户端直接从共享客户端下载。
>> > - 全分布式：在这个模式中，没有中央服务器，采用类似DHT式分布式哈希表技术，共享文件的注册和将针对文件名的查询都被哈希到不同的客户端执行。
>>
>> > 这两种模式相比较的话，显然全分布式的扩展性和隐私性更好，但是实现起来复杂，而且如果网络客户端数量少的，其查找的效率是很低的。集中式实现起来简
>> > 单，但是需要用到中央服务器，可能会带来一定的成本...
>>
>> > 看看大家还有什么好办法?

--

[Zoom.Quiet]

在 2011年4月14日 上午9:31，Zoom.Quiet <zoom....@gmail.com> 写道：
...
>> 实现这个功能有很多种技术选择，但是考虑到扩展性的话，基本上剩下两种P2P网络：
...

>> - 全分布式：在这个模式中，没有中央服务器，采用类似DHT式分布式哈希表技术，共享文件的注册和将针对文件名的查询都被哈希到不同的客户端执行。
>>

“分布式哈希”和“一致性哈希”的概念与算法实现
http://stblog.baidu-tech.com/?p=42
以及其中提及的论文，as atta.
- 这其实就是个非常轻型的 p2p 机器列表的维护算法了

[LiteBook.Author]

> >> - 全分布式：在这个模式中，没有中央服务器，采用类似DHT式分布式哈希表技术，共享文件的注册和将针对文件名的查询都被哈希到不同的客户端执行。
>
> "分布式哈希"和"一致性哈希"的概念与算法实现
> http://stblog.baidu-tech.com/?p=42
> 以及其中提及的论文，as atta.
> - 这其实就是个非常轻型的 p2p 机器列表的维护算法了

多谢，我之前也是在看这个Kad算法，好像还蛮流行的，蛮多p2p软件都实现了.

> Kademlia协议原理简介.pdf
> 321KViewDownload

[LiteBook.Author]

On Apr 13, 8:18 pm, "Zoom.Quiet" <zoom.qu...@gmail.com> wrote:

> 在 2011年4月14日 上午11:16，LiteBook.Author <litebook.aut...@gmail.com> 写道：
>
> > On Apr 13, 6:36 pm, 马剑 <honeyday...@gmail.com> wrote:
> >> 建议做平台工具，去搜书。
> >> 如果提供内容的话，很快就会翘辫子的。
>
> > 服务器上不提供内容，仅提供搜索服务，下载是从客户端到客户端，这样也有问题？
>
> - KAO！ 海盗湾不就是这么倒的！？

那个，http://thepiratebay.org/ 我这还能访问。。。
不过的确好像有点风险，也许还是做全分布式的比较好。

[Chunlin Zhang]

在 wikipedia 上看到 kademlia 的 python 实现库就有 3 个

2011/4/14 Zoom.Quiet <zoom....@gmail.com>:

[LiteBook.Author]

On Apr 13, 11:13 pm, Chunlin Zhang <zhangchun...@gmail.com> wrote:
> 在 wikipedia 上看到 kademlia 的 python 实现库就有 3 个
>

是的，那个我也看到了，不过目前想先试试自己实现一个。 顺便学习一下python socket编程，twisted什么的。

> 2011/4/14 Zoom.Quiet <zoom.qu...@gmail.com>:

[Chunlin Zhang]

另外你是不是只瞄准 txt 文件?

还有如果是文本资源共享的话,资源本身的质量评分系统应该要考虑,否则会变成大部分是质量很差或者文不对题或者重复章节很多之类的,至少要让用户能够看到别人的评价.不过这个对于分布式的估计又不好做.

2011/4/15 LiteBook.Author <liteboo...@gmail.com>:

[马剑]

最好能支持kindle。

3G版的kindle 3可以免翻墙的上任何网站，还不花钱，看书神器，一定要考虑支持一下哦！！！！

[LiteBook.Author]

On Apr 14, 7:52 pm, 马剑 <honeyday...@gmail.com> wrote:
> 最好能支持kindle。
> 3G版的kindle 3可以免翻墙的上任何网站，还不花钱，看书神器，一定要考虑支持一下哦！！！！

我目前在做的另外一个功能就是Litebook和手持设备之间的图书共享，基本上litebook会有一个内置的web server，手持设备上看书
程序可以通过其下载分享的图书，另外还会有一个生成EPUB文件的功能。目前考虑支持的app有IPHONE上的Stanza和ibook，另外针对
Stanza还会支持组播DNS功能，以支持其的自动发现功能。
但是好像kindle不支持epub格式。。。
>
> 在 2011年4月15日 上午9:15，Chunlin Zhang <zhangchun...@gmail.com>写道：
>
>
>
>
>
>
>
> > 另外你是不是只瞄准 txt 文件?
>
> > 还有如果是文本资源共享的话,资源本身的质量评分系统应该要考虑,否则会变成大部分是质量很差或者文不对题或者重复章节很多之类的,至少要让用户能够看到别人的 评价.不过这个对于分布式的估计又不好做.
>
> > 2011/4/15 LiteBook.Author <litebook.aut...@gmail.com>:

[LiteBook.Author]

On Apr 14, 6:15 pm, Chunlin Zhang <zhangchun...@gmail.com> wrote:
> 另外你是不是只瞄准 txt 文件?

和文件格式没有关系，理论上任何类型的文件都可以。
>
> 还有如果是文本资源共享的话,资源本身的质量评分系统应该要考虑,否则会变成大部分是质量很差或者文不对题或者重复章节很多之类的,至少要让用户能够看到别人的 评价.不过这个对于分布式的估计又不好做.

做这个关键在于如何唯一确定一本书的ID，这个也不太容易。

>
> 2011/4/15 LiteBook.Author <litebook.aut...@gmail.com>: