- 主题:关于合力开发第三套bbs访问接口的建议(草稿)
我也感觉现在的bbs内容越来越多，就像滚雪球
但基础的那些机制或者说框架没有变化
大多数站点都疲于查漏补缺
前几年的讨论我也看过一些，中心思想是用线程取代进程，个人觉得仅仅
这样是不够的，投入产出比小，只是意图减小进程上下文切换时间、共用
地址空间等等，基础的框架没有变化。lilybbs的zhch尝试用数据库存储版面，
可惜我没有使用过，遗憾。
【 在 windtear. 的大作中提到: 】
: 是这样的
: 以后进入开发的门槛会越来越高
: 数据和代码越来越混杂在一起
: 动一处而牵全身
: 前一段类似的讨论也不少
: 不过也只是讨论讨论
: 没人做啊
: 除非他把上帝挟持了
: 【 在 slowaction.bbs@bbs.tju.edu.cn.no.spam (王百万) 的大作中提到: 】
: : 中国的bbs站不过100多个
: : 有能力独立进行大规模开发的就很少
: : 很多站的维护工作都是为了正常的运行
: : ...................
--
FROM 218.79.100.157
线程只是一个方面，理论上可以减少上下文切换时间，共用地址空间的优点
不知道你所说的那种线程bbs是否源自以线程取代进程运行的思路（还是1对1模式）
如果是那样，那和我们的设想还是有很大区别的。我们设想是以限定数目
(例如16个)的线程服务小于1000个的用户连接，每个线程能处理的只是协议指令。
特定于bbs这种文件信息服务，文件缓冲也是一个可以优化的主题
用户操作界面相关的处理也可以省掉，交由用户端自行解析，有望减小服务器负荷
BBS的I/O是上载远小于下载，这一特性也是可以考虑利用的
【 在 lepton 的大作中提到: 】
: 线程bbs已经有人写一个了
: 【 在 peacock (孔雀@ytht) 的大作中提到: 】
: : 目前国内的bbs基本都是火鸟系统，基于telnet协议和http协议。
: : 1）telnet接口：核心思想是将远程的用户端虚拟为一个键盘和一个虚拟显示终端，
: : 这种接口的所有的交互都是基于过程；每个用户对应一个socket连接、一个进程。
: : 当用户达到五位数时，一般的系统难以承担运行负荷；
: : 2）http接口：对于超时的控制没有很好的解决，一般都使用间接手段；
: (以下引言省略...)
--
FROM 218.79.100.157
那是你没有看到，其实早就有人想过了，不过这个东西，第三方人是做不来的
而各 bbs 系统维护因为工作量的问题，对这个兴趣缺缺
你的这个想法，浙江大学的 fuse 两年前都做出来成型的东西了，叫 CQ66
最后还是因为维护太过费力而放弃了，其实他这种只有一个站在开发的情况
在起步时候应该还更容易发展，毕竟不用在不断的协议扩展中和其他站台扯皮
结果最后因为维护力量不足放弃了。
这个想法只是略微比数据库 bbs 和分布式 bbs 两个月经贴要少见一点
但是并不是没有人想过/做过
【 在 peacock.bbs@ytht.net (孔雀@ytht) 的大作中提到: 】
: 我也感觉现在的bbs内容越来越多，就像滚雪球
: 但基础的那些机制或者说框架没有变化
: 大多数站点都疲于查漏补缺
: ...................
※ 修改:·kxn 于 Mar 29 17:22:45 修改本文·[FROM: 166.111.3.239]
※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.3.239]
修改:kxn FROM 166.111.3.239
FROM 166.111.3.239
线程不太懂。。可以考虑使用数据库啊:)
lilybbs曾经装起来过，功能还比较有限，也没有使用共享内存等等
效率上还没有做太多的考虑。
【 在 peacock.bbs@ytht.net (孔雀@ytht) 的大作中提到: 】
: 我也感觉现在的bbs内容越来越多，就像滚雪球
: 但基础的那些机制或者说框架没有变化
: 大多数站点都疲于查漏补缺
: 前几年的讨论我也看过一些，中心思想是用线程取代进程，个人觉得仅仅
: 这样是不够的，投入产出比小，只是意图减小进程上下文切换时间、共用
: 地址空间等等，基础的框架没有变化。lilybbs的zhch尝试用数据库存储版面，
: 可惜我没有使用过，遗憾。
: 【 在 windtear. 的大作中提到: 】
: : 是这样的
: : 以后进入开发的门槛会越来越高
: .................（以下省略）
--
FROM 211.87.199.85
并非是个坏消息，只不知在哪里还能down一个
google了半天，都没找到关于cq66的正面文档
只有看过cq66之后才合适评头论足
btw: 楼上发贴的语气能不能稍稍调整一下
【 在 kxn (这花花世界没我的份) 的大作中提到: 】
: 那是你没有看到，其实早就有人想过了，不过这个东西，第三方人是做不来的
: 而各 bbs 系统维护因为工作量的问题，对这个兴趣缺缺
: 你的这个想法，浙江大学的 fuse 两年前都做出来成型的东西了，叫 CQ66
: ...................
--
FROM 202.119.32.*
线程和进程并没有多达区别，关键是do_fork()时，线程会选择共用地址空间
等参数，具体可以看一下pthread实现
【 在 esby.bbs@daibei.net (衣上白云) 的大作中提到: 】
: 线程不太懂。。可以考虑使用数据库啊:)
: lilybbs曾经装起来过，功能还比较有限，也没有使用共享内存等等
: 效率上还没有做太多的考虑。
: ...................
--
FROM 202.119.32.*
现有的telnet和www方式的bbs/forum有个特点就是
用简单的telnet client和浏览器就可以实现，而你的新
协议会导致用户使用困难。需要特定的客户端才行。
还有，其实这些与newsgroup以及现在的rss feed有不少相似
之出，有没有考虑使用现存的协议呢？
【 在 peacock 的大作中提到: 】
: 目前国内的bbs基本都是火鸟系统，基于telnet协议和http协议。
: 1）telnet接口：核心思想是将远程的用户端虚拟为一个键盘和一个虚拟显示终端，
: 这种接口的所有的交互都是基于过程；每个用户对应一个socket连接、一个进程。
: 当用户达到五位数时，一般的系统难以承担运行负荷；
: 2）http接口：对于超时的控制没有很好的解决，一般都使用间接手段；
: 对此我了解不多，我只想针对telnet协议进行一些讨论。
:
: (以下引言省略...)
--
FROM 210.51.19.226
具体的用户接口与协议实现没有多大关系
可以做到兼容现有的操作方式，对具体使用不会有多大影响
【 在 amino (xixi) 的大作中提到: 】
: 现有的telnet和www方式的bbs/forum有个特点就是
: 用简单的telnet client和浏览器就可以实现，而你的新
: 协议会导致用户使用困难。需要特定的客户端才行。
: 还有，其实这些与newsgroup以及现在的rss feed有不少相似
: 之出，有没有考虑使用现存的协议呢？
: 【 在 peacock 的大作中提到: 】
: : 目前国内的bbs基本都是火鸟系统，基于telnet协议和http协议。
: : 1）telnet接口：核心思想是将远程的用户端虚拟为一个键盘和一个虚拟显示终端，
: ...................
--
FROM 202.119.32.102
兼容目前的现有操作方式的线程bbs有人写过了
【 在 peacock (孔雀@ytht) 的大作中提到: 】
: 具体的用户接口与协议实现没有多大关系
: 可以做到兼容现有的操作方式，对具体使用不会有多大影响
: 【 在 amino (xixi) 的大作中提到: 】
: : 现有的telnet和www方式的bbs/forum有个特点就是
: : 用简单的telnet client和浏览器就可以实现，而你的新
: : 协议会导致用户使用困难。需要特定的客户端才行。
: : 还有，其实这些与newsgroup以及现在的rss feed有不少相似
: : 之出，有没有考虑使用现存的协议呢？
: ...................
--
FROM 162.105.161.3
线程写的程序
如果一个地方崩了 全站就崩了
进程最多崩掉这个用户
【 在 peacock (show me more) 的大作中提到: 】
: 线程和进程并没有多达区别，关键是do_fork()时，线程会选择共用地址空间
: 等参数，具体可以看一下pthread实现
--
FROM 162.105.31.*