目前国内的bbs基本都是火鸟系统，基于telnet协议和http协议。
1）telnet接口：核心思想是将远程的用户端虚拟为一个键盘和一个虚拟显示终端，
这种接口的所有的交互都是基于过程；每个用户对应一个socket连接、一个进程。
当用户达到五位数时，一般的系统难以承担运行负荷；
2）http接口：对于超时的控制没有很好的解决，只能一般都使用间接手段；
对此我了解不多，我只想针对telnet协议进行一些讨论。


现行的telnet接口，结构日渐陈旧，个人认为对于超大网络社区效率偏低，
对于bbs这种特定的信息服务不具备针对性：
（1）整个的交互是基于过程的，导致大量非必要运算和流量。例如，用户要想在
bbsdev版发表这篇文章，大多数用户都会先进入0区，找到bbsdev版，然后进入该版，
敲入ctrl+p，然后填写标题，再然后确定文章的属性，再然后才能编辑文章内容；
通过引入协议指令，可以避免这一问题。

（2）服务器承担所有的运算载荷。所有的运算处理都是在服务器上进行的，例如，
编辑文章，发送email等等，占用了绝大部分的处理能力，而telnet接口没有考虑利用
用户端的处理能力，来减轻服务器负荷；

（3）没有缓冲机制。主要是文件缓冲，针对bbs，大多数版面的绝大多数历史文章
都是非常稳定的；另外，很多用户很多情况下都是在几个版面、文章之间来回切换。
有效的对这种特性加以利用，势必可以大幅度减少网络I/O，减轻服务器的负载；

（4）结构不清晰。要增加一个新的功能就要考虑从输入到输出，以及和用户的交互
界面等的若干细节，只要任一功能运算出现错误，就会出现异常退出等问题。

基于以上考虑，在此提出我的建议：
（1）为bbs设置一种专用协议：bbs协议。并为这种协议开发专用的终端，这样可以
有效解决上述的（1）（2）（4）问题。初步估计了一下，指令数不会很多，这种
可以进行有效的扩充和升级；ptt利用底层浏览器，实现了一个自己特色的简单浏
览器，这种做法比较有新意；

（2）在bbs协议中增设缓冲机制。主要是对于版面列表、文章列表等内容的缓冲，
当然还有精华区、个人文集等类似数据体。这样，文章、精华贴、邮件下载就很
变得很简单了。

（3）将特殊服务、游戏、穿梭等内容作为一个独立的、与版面服务等重的服务，在
协议中，单独加以设计，因为这一部分相对变化较快；

（4）在“分区”这一概念之上，增设“主题”概念。版面服务是一个主题，服务是
一个主题，以后可以考虑的社区网络游戏也是一个主题，等。

（5）服务器断数据存储仍旧沿用现有结构。主要是为了平滑过度，但要考虑兼容
数据库存储方式以及多机分布存储，这样有利于实现信息共享。

（6）抛弃一对一的进程/用户服务机智。参考apache的进程池运做方式，在一个进程
内容纳提供16个服务线程，由select监视用户I/O，一旦发现，即将其生成一请求交
由任一空闲线程处理并返回结果。由于select监视数量有上限（1024），可以将每个
进程的用户数限定为1000，这样5万用户即需要50进程。

（7）线程内存尽量采用静态分配，减少系统符合。

（8）着力建造面向cernet用户的大型网络社区，不能只是一种版面服务。


需要着重考虑的问题：
（1）bbs协议的设计;
（2）数据的并发访问控制：需要建立结构化的锁机制；
（3）bbs协议无缝升级：考虑增加版本控制，自动升级的方式；
（4）xml的使用：希望可以用来解决数据结构化的问题；

**************************************************************
具体开发可以分几步：
（1）先构建基础bbs协议，实现分区、版面、文章（含邮件）、精华区（含个人
文集）的访问：代码量肯定会比现有的telnet接口小很多，因为界面、交互等相关
代码可以全部省掉，而这一部分在telnet接口中是占非常大比重的。并且开发这样
的框架，不需要对现有bbs接口有多少了解，门槛很低；
（2）基于bbs协议，建造其他服务，扩充bbs协议指令；



以前也曾经看到过线程牌bbs的提议，但都只限于讨论，希望对此有兴趣的网友，
能够联合起来做点事情，建造一种面向超大网络社区的BBS服务，取代台湾框架。

欢迎回复或者站内email，谢谢阅读。
--
FROM 218.1.126.74