主从式电子布告栏系统传输协定

Client/Server BBS Transfer Protocol (BBSTP)

林昱仁
摘要

　　在最近短短几年之中，台湾学术网路电子布告栏系统的发展非常快速，由初
期自国外引进时不到百人的使用人口，至目前由于国内对该系统不断的自行修改
与开发新功能，以至如今百花争鸣蔚为风尚的地步，整体的使用者人口成长到几
万至几十万人之众。随着网路环境的变迁，多媒体的使用环境已是必然趋势，并
且由于电子布告栏系统使用人口的快速成长等等因素，这些接踵而来的需求在目
前台湾学术网路电子布告栏系统的设计使用方式上就衍生出不少问题以及发展上
的障碍出现。一个以主从架构方式的电子布告栏系统正足以解决上述这些所遭遇
的问题。作者在此文中针对于主从架构电子布告栏系统的起因、相关背景、设计
概念、协定内容、与系统分析等部份加以一一的探讨与说明，希望能藉此加速国
内有关主从架构电子布告栏系统的发展进度，使得标准统一的协定能早日出现。
内容

＜前言＞
＜相关背景＞
＜系统分析＞
＜传输规格标准＞
＜详细的指令与回覆＞
＜结论＞
前言

　　在台湾学术网路电子布告栏系统的发展过程之中，可说是超乎大家的预期；
在使用人口方面，由当初开始时几百位使用者到目前的几万至几十万个使用者；
在架设的电子布告栏系统数量方面，由最初只有一两个电子布告栏系统到如今已
有上百个电子布告栏系统的存在；在使用的系统方面，由原本使用国外所设计的
系统至目前自行改进与设计，已超越了国外最初的设计，这种种都在国内网路的
使用上创造了不少特例。　　　　　　　　　　　　　　　　　　　　　　　　
　　电子布告栏系统最初的设计目的是一整合了讨论区、信件与交谈功能的系统
，本是属于小型区域性的使用特性。然而，随着国内在使用者需求与功能设计上
的改变，目前已渐渐朝大型广域的使用特性上转变。原本电子布告栏系统与外界
互不相关的特性也产生变化，台湾学术网路上各电子布告栏系统之间以及电子布
告栏系统与其它网路系统之间都已产生互动相互的影响。各电子布告栏系统讨论
区中的信件已可经由 News 系统来达到互相交换的目的，而区域性的信件功能也
扩展到可以做网际网路电子邮件的传输功能，谈天室功能也扩展到 IRC的使用方
式，这种种的改变使得台湾学术网路电子布告栏系统对网路的影响力大增。伴随
着电子布告栏系统的发展，使用者的增加快速使得各电子布告栏系统的使用呈现
饱和状态达到系统极限，并且因应网路目前发展趋势能够有视窗化介面的操作方
式与具备多媒体的特性，以及将系统工作能有效的加以分散而不致于像如今般全
然集中于单一的机器之上，为了解决上述这些问题，因此以主从架构方式的电子
布告栏系统变成为大家所想到的一个解决办法。　　　　　　　　　　　　　　

相关背景

　　目前主从架构电子布告栏系统的发展在国内各校中皆有不同的设计与研究发
展在进行中，然而，如今有正式公开且拥有较多人使用者的系统主要有下列二者
，说明如下：　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
PowerBBS 系统

　　PowerBBS 系统为由国内所自行设计，整套系统皆是以主从架构为主体，使用
者在使用此系统时需要有专属的客户端程式方可使用。由于此系统不同的设计，
其操作方式与功能特性与一般多数的台湾学术网路电子布告栏系统并不相同，而
是较接近仿间单纯以电话拨接使用的电子布告栏系统。在此系统协定的设计方面
，虽然其不是以 TELNET 的方式来上线使用，但在所使用的主从协定设计上则是
与 TELNET 所用协定的基本精神有些相似处，主要是以画面资料传输为主，意即
是当 SERVER 端接收到 CLIENT 端使用者的操作命令后，将其想要让使用者见到
的画面资料传给 CLIENT 端来显示。在此种方式的设计下，SERVER 端将具有较大
的变化弹性，也就是指 SERVER 端可更改使用者所见到的画面形式，但是相对来
说在 CLIENT 端即拥有较小的弹性，无法自行决定其想要的资料编排方式。在此
种方式下主要的工作将仍然由 SERVER 端来负责完成，无法有效分散 SERVER 的
负担，除非在 CLIENT 端以 CACHE 的设计方式来记忆保留些许资料，若使用者有
需要重覆使用时可以不需再至 SERVER 端取用。　　　　　　　　　　　　　　

FormosaBBS 系统

　　FormosaBBS 系统是在目前使用的 TELNET 方式系统下，再设计出一主从架
构协定给 CLIENT 与 SERVER 端程式使用。此种方式与原先的 TELNET 方式保
持并存，两者对相同的资料来进行存取，因此除了在使用方式上有所差异外，对
于连接上同一电子布告栏系统的使用者来说，其所见资料皆是相同的，而两种方
式的使用者间仍然可以互通讯息，如进行线上的交谈。这种设计的方式在基本上
与作者所提出的协定是相同的。不同之处只是其在设计上是以原 FormosaBBS 为
考量，因此在协定设计上有不少是以其专属的特性为考量因素，在某些设计上并
不完全适用于其它各版本电子布告栏系统程式的设计特性。　　　　　　　　　

系统分析

　　主从架构方式的电子布告栏系统与现行以 TELNET 为主的电子布告栏系统在
各方面皆有不同之处，以下将就各方面的不同一一加以说明。在上站方式上，目
前的 TELNET 方式对很多人来说简单方便，这是因为在多数网路环境下皆有此程
式可以直接使用。而主从架构的方式则须要再另外安装特别的专属 CLIENT 端程
式方可使用，因此若是版本更新时使用者需再安装新版的程式；更甚者若是各电
子布告栏系统由于协定的不同而有不同的 CLIENT 端使用程式，则使用者要上不
同的电子布告栏系统尚需要不同的程式才行，如此将造成使用者的麻烦。在操作
方式上，TELNET 之使用皆为单纯的键盘操作且为文字模式，而在主从架构下则可
以设计为图形介面的的使用者环境并且运用滑鼠的方式来加以操作控制，此外尚
可加入多媒体的特性发展成为一多媒体电子布告栏系统。在系统的负担上，主从
架构的设计优点之一是可减轻电子布告栏系统系统本身的负担，将原先部份工作
分配给 CLIENT 端的程式来加以处理，这样可以减少系统的负载，避免将所有工
作集中于单一的主机上来执行。　　　　　　　　　　　　　　　　　　　　　

　　在系统程式的开发上，现今台湾学术网路电子布告栏系统的程式开发与修改
工作皆是由各站的系统管理者来负责，因此管理者的工作繁重。而以主从架构方
式的电子布告栏系统由于有公开的协定，其 CLIENT 端的应用程式可由使用者自
行加以开发，SERVER 端仅有担任提供使用者所需基本资料的角色，至于资料的
再次加工处理与展现方式则由 CLIENT 端的设计者自行决定。在此种方式之下，
电子布告栏系统系统管理者由原先需兼具有系统管理与程式开发两者的工作转变
为只需专注于对系统的管理一项工作即可，如此可以减轻许多负担。在系统的使
用人数上，以主从架构的设计方式不会受现行安装系统 TTY 数量的限制，可以增
加系统同时可容纳的线上使用人数。这是因为 UNIX 系统本身的设计限制，在目
前的 SunOS 4.1.x上经过修改后也只能容纳到 512 人。　　　　　　　　　　　

　　在应用发展上，以主从架构的方式所设计的电子布告栏系统来说，对于 CLIENT
端若要其将所连接的各不同电子布告栏系统 SERVER 之间的资源加以整合以做特
殊的统一利用将更为方便。　　　　　　　　　　　　　　　　　　　　　　　

BBSTP(Bulletin Board System Transfer Protocol)传输规格标准

指令

　指令是由一指令字组所组成，而某些指令字组后可能跟随着数个指令参数
　。这些指令字组是不分大小写的。指令字组与各参数间是以一个或多个的空白或是
　tab字元来加以分隔。每一个指令列是以一对CR-LF(Carriage Return - Line Feed
　)来做为结束字元符号，并且总长度不能超过 512 个字元。

回应

　有两种类别的回应，分别是文字回应和状态回应。

　　文字回应

　　　文字类别的回应是回应一连串的文字列，每列文字以一对 CR-LF 为结束。而此
　　　文字回应以单行包含单一的句点(.)，其后跟随着一对 CR-LF 做为整个文字回应的结
　　　束。若该行文字内容第一字为句点，则在传送时需将此一句点重覆，也就是传送两个
　　　句点。在接收端若发现该行不是代表结束的单一句点资料，且其第一字为句点的话，
　　　则去除掉此一句点(也就是发送端所重覆的资料)。

　　状态回应

　　　在回应端的状态回应列的启始是 3 位数的代码，此部份代码的意义就采用与
　　　NNTP 相同的分类意义如下：
　　1xx - 讯息资料。
　　2xx - 指令正确。
　　3xx - 指令尚未完成，需继续传送其它资料。
　　4xx - 指令正确但因某些原因而无效。
　　5xx - 指令未提供、错误或是严重的程式错误发生。

　　　这样分类的好处之一是将所有状态分类好, Client 端在判断时，除非有特别需
　　　要，否则 2xx、3xx 表示成功，4xx、5xx 就是失败。如此比较清楚，而不会在一
　　　连续的数字中，成功失败交叉混着，这样判断的状态会较复杂化。
　　　在此代码后跟随着一些参数，依回应的状态而有所不同，各参数间是以一个以上
　　　的空白或 tab 字元来加以区隔，最后同样以一对 CR-LF 为结束。

　　一般性的状态回应

　　　在一般性的状态回应约有如下这几个：
　　100 指令说明
　　200 bbs 电子布告栏系统 Server BBSTP Ready
　　400 Service unavailable
　　401 需先执行其它指令(如 Login 动作)
　　410 指令参数错误
　　500 指令错误
　　501 指令语法错误
　　502 access restriction or permission denied

详细的指令与回覆

　　在指令描述中，以中括号[] 括起者表示其中的资料是选择性资料，可选择任一参数指令。

6-1 连接回应

　　200 bbs Bulletin Board System Server BBSTP Ready
　　400 Connection refused for some reason

6-2 指令FILE

　　FILE

　FILE [issue | welcome | signature | plan | override]
　　此指令是用来要求 Server 传送一些系统或使用者的基本档案资料。其中，issue
　　为连上 BBS 但尚未 Login 前，Server 想告知 Client 之资料；welcome 为Login
　　成功后，Server 对于 Client 的公告资料；signature 为使用者的签名档；plan 为
　　使用者的计画档；override 为使用者的朋友名单资料。

　回应
　　202 File transfer - xxxx
　　在此一状态回应之后则跟随着实际内容的文字回应资料。

6-3 指令USER

　　USER

　USER userid
　　此指令是用来登录系统之用，需输入登录使用者之代码。视不同的 BBS 系统设计
　　，此使用者代码的大小写可能相关也可能无关。若使用者是要求注册一新的帐号，则
　　是以回应 310 的状态进行交谈式的新帐号资料输入。

　回应
　　210 user ok
　　211 User Login Success /* 使用者成功登录(不需密码) */
　　310 New User Register, request data /* 输入新使用者资料 */
　　319 New User Register, 保密资料 /* 表 Client 端输入时不显示 */
　　411 此资料不被允许

　　新帐号注册范例
　　　C): USER new
　　　S): 310 使用者代码
　　　C): sysop
　　　S): 411 此使用者代码已有人使用
　　　C): helios
　　　S): 319 使用者密码
　　　C): xxxxxxx
　　　S): 310 您想要取的绰号
　　　C): 我的绰号
　　　S): 310 真实姓名
　　　C): 林昱仁........
　　　S): 310 萤幕模式 (ansi,vt100,vt102,h19a,dumb,...)
　　　C): vt100
　　　S): 211 Login Success

6-4 指令PASS

　　PASS

　PASS passwd
　　此指令是用来输入使用者密码。

　回应
　　211 User Login Success /* 使用者成功登录 */
　　401 USER assign first /* 尚未指定使用者代码 */

6-5 指令LOGFAIL

　　LOGFAIL

　LOGFAIL [get | clear]
　　此指令是用来要求/清除使用者 Login 失败记录资料，其中 get 为要求资
　　料；clear 为清除资料。

　回应
　　224 data follows /* 之后为文字回应之资料 */
　　210 loginfail clear ok

6-6 指令MULTILOG

　　MULTILOG

　MULTILOG [get | kill] [辨识代码]
　　此指令是用来要求(get)使用者的重覆 Login 资料，亦或是清除(kill)使用者
　　之重覆 Login。

　回应
　　224 data follows /* 之后为文字回应之资料 */
　　210 Multi-Login kill ok

　文字回应资料
　　在 MULTILOG get 中的文字回应资料每列格式如下：
　　　[辨试资料]tab[上站地点]tab[目前状态]

6-7 指令TIME

　　TIME

　TIME [system | welcome | bnote]
　　此指令是用来要求 Server 有关时间的资讯。其中，system 是目前系统的
　　时间；welcome 是系统 welcome 资料的最近更新时间；bnote 则是目前
　　所选择讨论区之welcome 资料的最近更新时间。所回应的 time-stamp 值为
　　从 00:00:00 GMT, Jan, 1, 1970 所算起的秒数，若无此资料则回应的 time-
　　stamp 为 0。

　回应
　　203 [time-stamp] time

6-8 指令MAIL

　　MAIL

　MAIL [userid]
　　此指令是用来询问使用者信箱的基本资料，包含了未读的信件数(#unread)
　　与全部的信件数(#total)。若不加 [userid] 参数表示询问的是登录使用者本
　　身资料。

　回应
　　220 [#unread] [#total] mail

6-9 指令BOARD

　　BOARD

　BOARD [boardname] [zap|unzap]
　　此指令是用来选定所要的讨论区，参数为讨论区名称，并可选择此讨论区
　　是否要隐藏(zap)起来。回应的状态资料有此讨论区的文章总数(#total)与该
　　使用者最近使用该讨论区的时间(last-visit-time-stamp)。

　回应
　　211 [#total] [last-visit-time-stamp] boardname

6-10 指令LIST

　　LIST

　LIST [boards]
　　此指令是用来要求列出目前所有讨论区的相关资料。

　回应
　　224 data follows

　文字回应资料
　　在 LIST boards 中的文字回应资料每列格式如下，其中，[等级]部份资料，
　　'y' 表此讨论区可以张贴，'n' 表不可以张贴。[投票状态]部份资料，'V' 表
　　投票中，'R'表投票结束。[Zap状态]部份资料，'Z' 表此讨论区使用者是设
　　定隐藏起来，'Y' 表示非隐藏状态。而各栏位的资料长度基本上并无限制。

　[讨论区名称]tab[等级]tab[描述]tab[板主]tab[投票状态]tab[Zap状态]

6-11 指令OVER

　　OVER

　OVER [board | mail] LowNumber [HighNumber]
　　此指令是用来要求对目前讨论区(board)或私人信箱(mail)中之单封文章或
　　是一个范围的文章(加上 HighNumber 参数)之简短描述资料。

　回应
　　224 data follows

　文字回应资料
　　在 OVER [board | mail] LowNumber [HighNumber] 中的文字回应资料每列
　　格式如下，其中，[序号] 表文章编号从 '1' 开始。[阅读状态] 为 ' ','N','m','M'
　　,... 等状态。[作者] 部份站内使用者为使用者代码，站外使用者为其 E-mail
　　Address。[时间] 为 time-stamp 格式。

　[序号]tab[阅读状态]tab[标题]tab[作者]tab[时间]tab[档案名称]

6-12 指令POST

　　POST

　POST [board | mail] [local]
　　此指令是用来在目前所选择讨论区中张贴文章(board)，或是送出一封私人
　　信件(mail)。

　回应
　　340 send article to be posted. End with .
　　440 post not allowed

　文章(信件)格式
　　在 POST [board | mail] 中当状态回应为 340 时，Client 需继续送文章资
　　料，此文章资料格式可参考 RFC850 中之规定，内容为文章的标头资料加
　　上文章的本文所组成，若最后有加上 local 参数表此文章设定为 local save
　　状态。文章的标头资料有 Subject: 与 To: 两者，举例如下：

　340 send article to be posted. End with .
　Subject: this is a test subjectTo: helios, sysop, gis83504@cis.nctu.edu.tw
/* 或是多个 boardname */
　This is article body.

6-13 指令INFO

　　INFO

　INFO [system | user] [userid]
　　此指令是用来提供系统及使用者资讯之用。在 INFO user 指令中若加入一
　　userid 参数，则表示要查询的是其它使用者的资料(相对于目前的 Query
　　功能)，否则是显示目前使用者的基本资料。

　回应
　　202 File Transfer - xxx

　文字回应资料
　　在 INFO system 中的回应资料为提供系统资讯之用，其格式为 keyword =
　　value的型态，一般的 keyword 为 BBSID，BBSNAME，BBSDOMAIN ...
　　等资料。至于 INFO user 的指令，若其后有加上 userid 参数表
　　查询其它使用者的资料，则传回的文字资料为一画面无特定格式意义存
　　在；若是不加 userid 参数表查询使用者本身资料，此资料以如同 INFO
　　system 相似的格式传回，为 keyword = value 的方式，而可能的 keyword
　　为 ID，NickName，Email，Login#，Post#，... 等。

6-14 指令 ANNOUNCE、BDIGEST

　　ANNOUNCE

　ANNOUNCE [path]
　　此指令是用来获得该 BBS 站公布栏之资料。此指令之Protocol与Gopher
　　相似，当 [path] 参数不给时所获得的是最起始页的资料。而 BDIGEST 指
　　令与 ANNOUNCE 相似，所不同的是 BDIGEST 所获得的是目前所选择
　　讨论区的精华资料。

　回应
　　224 data follows

　文字回应资料
　　回应的文字资料格式如下：[type] 表此项目的种类，'0' 表示为档案，'1' 表
　　示为目录。[path] 为要获得此项资料的 path 参数。[site] 若有的话表示此
　　项为一 Gopher Link，可依 path, site, port 三者之资料依 Gopher protocol 与
　　指定 Gopher 连接获得资料。[更新时间] 为此项目的最近更动时间。

　[type]tab[描述]tab[path]tab[site]tab[port]tab[更新时间]

6-15 指令EGROUP

　　EGROUP

　EGROUP [path]
　　此指令是用来获得该 BBS 站讨论区分类群组之资料。当 [path] 参数不给
　　时所获得的是最起始页的资料。

　回应
　　224 data follows

　文字回应资料
　　回应的文字资料格式如下：[type] 表此项目的种类，'0' 表示为讨论区，'1' 表
　　示为分类群组。[path] 为要获得此项资料的 path 参数，若此项为讨论区
　　则path为此讨论区之名称。

　[type]tab[描述]tab[path]

6-16 CHATROOM Protocol

　　在 CHATROOM Ptotocol 设计上是以新的 EagleBBS 3.0 的 chatroom 为
　　参考依据，使用者可以由 INFO system 指令中的 CHATPORT keyword 得
　　知 chatroom port所在，自行与 CHAT Daemon 沟通。
　　当连上 chatroom daemon 后，所输入的第一列指令如下：
　　　/!
　　输入此行后，chatroom daemon 的回应为两个字元，如下所定义：
　　　#define CHAT_LOGIN_OK "OK"
　　　#define CHAT_LOGIN_EXISTS "EX"
　　　#define CHAT_LOGIN_INVALID "IN"
　　　#define CHAT_LOGIN_BOGUS "BG"
　　，OK 表示顺利进入。EX 或 IN 表示 chatid 不允许，可重换chatid
　　 /! 的指令。而 BG 表示资料错误(包含 unum, userid, passwd)，此情况
　　atroom daemon 将会把你的连接 socket 关掉。
　　之后，由chatroom daemon 所传回来的资料，每行的第一个字元若不是 '/'
　　显示于萤幕，若是以 '/' 开头则表示特殊意义如下：
　　　/c : 要求 client 端清除萤幕
　　　/n : 传回你新的chatid
　　　/r : 你进入的 room 名称
　　　/t : 你所在 room 的话题
　　而这些指定的资料都从第三个字元开始，就是紧跟在 /x 之后。

6-17 指令TALK

　　TALK

　TALK [userid] [talkport] [userno]

　回应
　　210 Command OK
　　450 TALK not allow for some reason

　运作方式
　　基本上，目前在 EagleBBS 系列的 BBS 中，其 Talk 的方式本就是透过
　　socket来传输资料，当 A 使用者要与 B 使用者交谈时，则会先建立一个
　　socket 来等待对方连接，然后送出一个 Signal 信号通知 B 有人要与其交
　　谈，而 B 使用者收到此讯号后，由系统中查出是 A 要与其交谈，以及 A
　　所建立的 socket port 为何，此时 B 就与 A 所建立的 socket 建立连线，
　　然后透过此连线告知 A 是否要与之交谈。因此当扩充此方式的 Client-
　　Server 架构时，所不同的是 A 通知 B 的方式，以及 B 向系统查询是谁
　　要与其交谈资料这两者在 Client 端会有所不同。
　　由于每个 Client 在 BBS 主机上都有一对映的 process 存在，因此在设计
　　上此一 process 与其它使用者在主机上 process 的运作关系就与原架构相
　　同，所要扩充的是在 Client 端的 process 与其对映主机上 process 彼此间
　　的沟通方式。当 Client 端想与其它使用者交谈时，则以 TALK [userid]
　　[talkport] [userno] 指令通知 Server，而 Server 收到此指令后则像原本一样
　　送一个 Signal 给所要交谈对象的 process 知道。当有人想要与 Client 使
　　用者交谈时，Client 在主机上对映的 process 会先收到通知，而此 process
　　就可向系统查询对方的资料，然后将此资料以下列格式传给 Client 端知
　　道。则 Client 端可以依此资料自行与对方连接告知是否要与对方交谈。

　page [userid]tab[username]tab[fromhost]tab[talkport]

6-18 指令WRITE

　　WRITE

　WRITE [userid]tab[Msg]tab[userno]

　回应
　　210 Command OK
　　450 WRITE not allow for some reason

　运作方式
　　WRITE 的运作方式与 TALK 是相同的架构，当 Client 端要发出 Write
　　讯息时则以如上指令的方式送出。而当 Client 端要接收 Write 资料时，
　　在主机上所对映的 process 则以如下的格式送出资料告知 Client。

　write [userid]tab[username]tab[Msg]

6-19 指令VOTE

　　VOTE

　VOTE [control | data | result] [boardname] [vote-str]
　　此指令是用于投票的相关功能上，可分为三类：一是获得投票资讯
　　(control)；二是投票(data)；三是得知投票结果(result)。若是系统投票以特殊
　　的 boardname (#system) 来取得。

　回应
　　210 VOTE OK
　　202 VOTE result data follows
　　340 Send vote data. End with .

　文字回应资料
　　VOTE control [boardname] [vote-str]

　　1.其中, 当 vote-str 不给的时后是得到目前此板所举行 vote 简短说明,传
　　　回格式如下：(若无投票传回的内容为空的)
　　[vote-str]tab[vote-short-desc] 836461537 投票简短描述
　　2. 若加上述所列 vote-str 后，则回传这项投票的相关控制讯息，如下：

　End-Time: Wed Jul 10 20:21:47 CST 1996
　Ballots: 2
　Items: A 我天天来看耶....always..
　Items: B 我几天才来看一次啦.....often...
　Items: C 我有时....sometimes..
　这是一次测试投票,这里是投票的完整描述说明.

　　预计是以像 Post 的方式传回相关控制讯息，一个 Header：Value 的方
　　式，End-Time: 这个 Header 显示结束时间。Ballots: 表示可投票数。
　　Items: 是此次投票可选的项目，其中后面 Value 的第一个字母是投票控制
　　用的字元，当然不定要是 A,B,C,.. 要用 1,2,3 或 @,$,^ 也都是可以的。在
　　所有标头结束后空一行空白，接下来是整个投票的完整描述说明，最后以
　　一行 '.' 当结束。

　vote data [boardname] [vote-str]
　　在下完此指令后 Server 回应状态 340 表示继续接收资料，此时 Client 可
　　送的资料格式如下：

　Ballots: AC
　Advice: 这次投票好烂....

　　同样是用类似一封 post 的方式，一个 Header: Value。Ballots: 所投的票
　　(如上是投 A,C 共两票)。Advice: 对此次投票给的意见。

　vote result [boardname]
　　传回目前所有的投票结果。

6-20 指令PUT

　　PUT

　PUT [signature | plan | override]
　　此指令是用来更新使用者个人资料档案，包含了签名档、计画档与朋友名
　　单。

　回应
　　340 Send data to be transfered. End with .
　　240 Data transfer OK

　文字传送资料
　　在 PUT [signature | plan] 下所传送的资料无特定格式，而在 PUT override
　　下所传送的资料格式，每列的第一个栏位资料为使用者代码。

6-21 指令BODY

　　BODY

　BODY [board | mail] Number [filename]
　　此命令是获得文章或信件的内容资料。

　回应
　　202 num body

6-22 指令DELETE

　　DELETE

　DELETE [board | mail] filename LowNumber [HighNumber]
　　此指令是用来删除一封或一个范围的文章资料。

　回应
　　210 article deleted

6-23 指令SEARCH

　　SEARCH,P> 　SEARCH [board | mail] [author | title] [a | p] [+ | - | *] Number Pattern
　　此指令是用来搜寻文章之用。[author | title] 表示是要对作者或标题搜寻。
　　[a | p] 表示搜寻是做全部符合或部份符合。Number 表示由第几封文章开
　　始搜寻。[+ | - | *] 表示搜寻的方向是向前、向后、或是全部搜寻。Pattern 为
　　所要搜寻的样本资料。

　回应
　　224 data follows

　文字回应资料
　　所回覆的文字回应资料格式与 OVER 指令是相同的。

6-24 指令SET

　　SET

　SET [pager | color] [on | off]
　SET userdata
　　此指令是用来设定使用者的基本个人资料与杂项属性资料。以 SET userdata
　　参数可以用相似于新使用者注册相同的对谈式 protocol 来更改使用者的个人基本
　　资料(此时若输入空白表示不更改此项资料)。而其它 SET [pager | color] [on | off]
　　等则可用来切换设定使用者的各项属性资料。

　回应
　　210 User character change ok
　　310 Modify User Data, Send Data (Empty for not change)

6-25 指令USERS

　　USERS

　USERS
　　此指令是用来获得目前站上所有线上使用者的列表。

　回应
　　256 online user list follows

　文字回应资料
　　此指令的文字回应资料格式如下：[userno] 为此使用者的识别码。[pagemode]
　　为此使用者的呼叫状态。[mode] 为使用者目前状态。[idletime] 为此使用者的
　　Idle 时间。[userno]tab[userid]tab[username]tab[from]tab[pagemode]tab[mode]
　　tab[idletime]

6-26 指令HELP

　　HELP

　HELP
　　此指令为查询系统所提供的指令。

　回应
　　100 Legal Commands

6-27 指令QUIT

　　QUIT

　QUIT
　　此指令是用来离开此系统，结束使用。

　回应
　　205 connection close -- good bye

结论

　　主从架构电子布告栏系统的发展在国内来说已有超过两年以上的历史，但是
在其使用的人数及推广上来说至今尚不普遍，这其中有种种的原因存在，最主要
的因素之一就是因为目前并没有一个统一的主从架构电子布告栏系统的协定出现
，也由此无法有统一的力量来推动。作者藉由对目前在网际网路上数种服务的通
讯协定加以参考也同时考虑国内各版本电子布告栏系统程式设计的特性与各相关
管理者的意见后，而提出此套主从架构电子布告栏系统通讯协定，希望能因此获
得广大快速的回响，使得一个标准的主从架构电子布告栏系统协定能够早日得到
共识，进而加速主从架构电子布告栏系统的使用在国内的推广进度，让众多的使
用者能有一个更佳的电子布告栏系统使用环境。　　　　　　　　　　　　　　
参考资料

1. B. Kantor, P. Lapsley, "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News", RFC 977.
2. F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. John,D. Torrey, B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", 03/18/1993, RFC 1436.
3. J. Postel, "Simple Mail Transfer Protocol", 08/01/1982, RFC 821.

联创：构建支撑系统的平衡之美

张有根分析了一段时间以来关于业界在BSS/OSS架构统一客户资料平台的论题。目前国内在BSS/OSS系统中成功建立一个统一客户资料平台的运营商还不多，在全球统一客户资料平台上的定位还不十分明确，它的业务驱动力到底在什么地方还有待于探讨。联创科技凭借丰富的支撑系统经验感觉到，统一客户资料平台所强调的仍然在数据层，以满足客户在跨区域、全电信业务方面的一个需求，同时也是对客户的360度视图的信息展示。客户平台业务驱动力主要来自三方面。第一是满足对客户端与端服务的流程全程闭环响应,这就要求客户层要融合，客户的全方位信息要共享，才能支撑客户端对端业务流程，为了加强 BSS/OSS系统内部核心的控制，在BSS/OSS中必须要有一个类似于核心网HLR的东西。第二是为业务支撑网及营销网提供统一客户信息的路由。第三是为整个BSS/OSS各大功能域交互数据的一个通路。

统一客户资料平台有些类似于GSM核心网的HLR，存有全网业务需求的客户资料。BSS/OSS系统各大功能域会有自己的客户数据，但是都是各自私有的。在营造统一客户平台资料的时候，很多的工作是做客户的360度视图以及全网业务，这是一个规划设计客户资源、客户全信息修订及发布的过程。目前中国电信的全网业务局限于省，中国电信希望在省内地市之间进行全网业务。中国移动是以省为中心建设的BSS/OSS系统，要在两个层面做全网业务，一层是全国性的，另一层是省级的。事实上客户资料的数据都会物理分布在不同的数据库当中，这是性能平衡没有办法的选择，所以客户资料数据没有办法完全放在一个数据库里。因此统一客户资料平台客户信息和分布在其他功能域的客户资料信息对客户统一信息视图就存在一对矛盾，怎样合理地解决矛盾，一直是影响从数据的模型到业务构件的设计,平衡设计统一客户资料平台数据模型是处理这对矛盾关键点。

李氏单词杀手
背单词可以说是学英语的最大障碍，单词量的缺乏往往是阻碍进步的第一关。市面上的单词软件也很多，但却各有弊端。背单词往往需要大量的重复，而不需要一些花里胡哨的功能。所以本人抽时间编了这个软件--李氏单词杀手。为自己，也为了广大有此需要的网友。
李氏单词杀手通过大量的重复，来加强对单词的记忆。并可实现一些特殊的功能，如：分词性背，分前、后缀背等。可以在短时间内完成大量的单词，（1个月应能达到5000--10000左右），特别适合单词背的模棱两可的你！快来吧，我们要把单词杀死，杀死，杀死！！

知音查词
当你学英语练听力、看英文电影的时候，有时听清楚了一个单词的音，却怎么也想不起它究竟是什么单词，翻英语词典吧，也难也找到，因为绝大多数英语词典是以字母为序的，不象汉语词典是按拼音排序的，知道了音，就能查到相应的汉字。知音查词就是为了解决上述的尴尬而设计的，只要输入音标就能查到相应的单词，还可以查同音词，查前面音节相同的单词，另外你还可以查发音的字母组合，学习音标规则，每天用一用，你的听力和发音更上一层楼。本软件内置30000单词，包括小学、初中、高中、大学、GMAT、GRE等单词。

Soundex Algorithm

1. Capitalize all letters in the word and drop all punctuation marks. Pad the word with rightmost blanks as needed during each procedure step.
2. Retain the first letter of the word.
3. Change all occurrence of the following letters to '0' (zero):
'A', E', 'I', 'O', 'U', 'H', 'W', 'Y'.
4. Change letters from the following sets into the digit given:
* 1 = 'B', 'F', 'P', 'V'
* 2 = 'C', 'G', 'J', 'K', 'Q', 'S', 'X', 'Z'
* 3 = 'D','T'
* 4 = 'L'
* 5 = 'M','N'
* 6 = 'R'
5. Remove all pairs of digits which occur beside each other from the string that resulted after step (4).
6. Remove all zeros from the string that results from step 5.0 (placed there in step 3)
7. Pad the string that resulted from step (6) with trailing zeros and return only the first four positions, which will be of the form .

双语例句检索引擎
哈工大信息检索研究室(Information Retrieval Lab)是哈尔滨工业大学(Harbin Institute of Technology)计算机科学与技术学院的一个研究室，正式组建于2001年3月，由刘挺教授担任常务负责人，目前有5名教师、7名博士生、13名硕士生。研究室承担着国家自然科学基金、国家863等多项国家级课题，在国内外发表学术论文50余篇。
研究室致力于互联网信息检索领域的研究，包括自然语言处理、信息抽取、信息过滤、竞争情报等。在技术推广方面，研究室主要通过与企业合作，采取将 技术嵌入企业的产品中的方式，实现研究的商业价值，回报社会。目前研究室可转让的技术包括：自动分词标注、依存句法分析、词义消歧、自动标引文摘、短信过 滤等。
哈工大信息检索研究室是一个年轻的团队，她渴望向国内和国际的同行们学习，也愿意尽自己的努力在计算机应用领域做出贡献。

双语例句检索引擎
在学习和使用外语时，双语例句常常比词条释义更有帮助。哈工大信息检索研究室将中文自动分词标注、中文依存句法分析、中文词义消歧和词义扩展、模 糊语义距离计算、中英双语语料自动句对齐和词对齐、中文句子索引与检索等多项关键技术融于一炉，研制出了中英双语例句智能检索引擎。
该引擎从大量双语例句中快速准确地检索出与用户提交的检索式最贴切的双语例句，用户可以参考例句，写出 正确地道的外语句子。双语例句检索功能和金山公司的词霸搜索功能相互配合，将为用户提供完美的外语学习和写作环境。

日课

曾国藩有“挺经”十八法，以下是我的“挺经”十六条

决心每日诵读两遍，融化到血液中，落实到行动上。

自强不息，厚德载物
志存高远，脚踏实地
顺应自然，简约务实
淡泊宁静，举重若轻
勤奋敬业，科技报国
培育英才，结交益友
孝顺父母，服从上级
体贴妻子，教子成人
诚意正心，从容中道
不疑不惧，果决力行
劲气内敛，谦虚谨慎
戒色戒斗，强身健体
乐观自信，心胸宽广
能立能达，不怨不尤
安守本分，知足常乐
返璞归真，童心不泯

三段论
今天悟出了一个道理，就称为“三段论”吧。

上段：必须做的事一定要努力去做
下段：绝对不能做的事情一定不要去做
中段：可做可不做，可以这样做也可以那样做的事情，应该顺应自然而为，不可拘泥。

对己对人，都是这个道理。如果没有上下两段，人就没有了原则，没有了立身之本，但如果上下两段太长，以至于中段太短，人就没有了自由，也失去了对于环境的自然的适应能力，就会变得刻板迂腐。

疏狂和拘谨都不好，要平衡，要中庸。

升华

消极情绪如何化解？我认为有如下四种方法：一是发泄，二是麻醉，三是忍耐，四是升华。

发泄又有两种：一种是伤害他人的，常常是迁怒，也就是伤害无辜的人，尤其是亲人，因为发泄者潜意识中认为伤害亲人是最安全的，能够得到原谅，不会得到报复；另一种是自我发泄，包括大喊大叫，摔砸东西，撕碎纸片等，这一种的好处是不伤害他人，但是摔东西一定要找便宜的物件，摔起来声音动听也就行了。

麻醉的典型是酗酒，喝他个人事不省，暂时忘掉烦恼忧愁。但是醒来后往往更痛苦，所谓“借酒浇愁愁更愁”。还有一种麻醉术是阿Q精神，吃不到葡萄就说葡萄酸，或者说自己根本就不喜欢吃葡萄，这种方法偶尔用用倒也罢了，用久了就会让人失去目标，失去锐气，失去自我。

忍耐是用厚厚的棉被把心头的火焰盖起来，告诉自己眼前的现实只有接受，没有别的办法。长期忍耐的结果要么是血压升高，人变得像一座火山，遇到机会就可能爆发，而且一发不可收拾；要么就是郁郁寡欢，人变得怯懦猥琐，失去活力。

升华，真正理想的心理调节术是升华。升华一种转化，而且是一种向上的转化。内心的升华不需要外界的力量，这一点有点象忍耐，但忍耐是把剑指向自己的心，而升华是找到一种高尚的观念作为缆绳，把自己从深渊拉起来送上高山，一切阴霾荡尽，眼前豁然开朗。比如遇到邻里间琐碎小事发生争吵，何不升华之，“我是做大事的人，怎能纠缠于这些小事浪费光阴，浪费精力呢？”；比如夫妻口角，何不升华之，“我是男子汉大丈夫，我保持理智，宽容妻子，更证明我的胸怀”；比如工作遇到挫折，何不升华之，“估计天将降大人于我，我又汲取了不少教训，变得更坚强了，吃一堑长一智，下一次我一定能够成功”。人生成败在乎一念之差，一个念头向上翻就是天堂，向下沉就是地狱。

把消极情绪升华，既可以避免伤害他人，避免损坏物品，避免摧残健康，避免压抑自我，又能够提升自己的人格，并在人格的提升中感受到自我成长的愉悦，何乐而不为？

关于授权


我在给下属授权方面做的始终不好，经朋友推荐阅读了《水煮三国》中关于授权的章节，有所收获，特摘录如下，以为日常借鉴。

-----------------------------------------------------------------------------------------
4.实现有效授权的九大障碍
新浪读书

　　刘备问：“听你的口气，授权好像很难吧？”

　　陈登说：“应该说，实现有效授权的最大障碍仍然在管理者自身。要克服这些障碍，的确有些难度。”

　　刘备说：“我懂你的意思。你说吧，为了实现有效授权，我应该怎样去克服这些障碍
？”

　　陈登从抽屉里抽出一本便笺，说：“归纳一下，大约有九大障碍。我列在纸上，好让您看得明白一些。”

　　障碍一：不信任员工

　　作为一位管理者，很多时候您会装出一副很信任部属的样子。然而，很多事实证明您放心不下。在具体的工作中，您没法不去过问您的部属是如何开展工作的，甚至把一些关键的环节留给自己亲自操作。您在自己的心里打了个很大的问号，您的部属会像你一样尽职尽责吗？

　　也许，您的担心是有原因的，有些员工的工作绩效总是不能做得像你预期的那样好。然而，一味地批评抱怨又有什么用呢？如果您怀疑员工的人品，您应该问问自己，是不是因为您没有通过信任来激励他们；如果您怀疑员工的工作能力，您应该也问问自己，有没有对他们进行必要的培训或给他们锻炼的机会？总而言之，您应该反复寻找失利的原因，然后和大家一起探索提升业绩的办法。事实就是这样简单，通过您的信任、鼓励和培养，您的部属终将会成长为一个真正值得您信赖的人。

　　障碍二：害怕失去对任务的控制

　　很多管理者之所以对授权特别敏感，是因为害怕失去对任务的控制。一旦失控，后果很可能就无法预料了。问题是：难道您非得把任务控制在自己手中吗？可不可以通过合适的手段避免任务失控呢？

　　只要您能够保持沟通与协调的顺畅，采用类似“关键会议制度”、“书面汇报制度”、“管理者述职”等手段，强化信息流通的效率与效果，任务在完成的过程中，失控的可能性其实是很小的。同时，在安排任务的时候，您应该尽可能地把问题、目标、资源等，向部属交代清楚，也有助于避免任务失控。

　　另外，管理者和员工也很容易在解决问题的方法上产生分歧。由于您相信自己的经验，您甚至会强迫部属执行您的意见，致使部属不愿意对任务负责。其实条条大路通罗马，问题的关键不是方法，而是结果。一些具体的处理细节，您完全可以授权给自己的部属来全权处理。也许，在此过程中，您的下属能够创造出比您的经验更科学、更出色的解决办法呢！

　　障碍三：过高强调自己在组织中的重要性

　　由于您很能干，在很多时候您会产生“什么事情离了我不行”的错觉。是的，也许您能够成功地完成许多任务，但您得像孙悟空一样分身有术才行。

　　其实，你的下属就是你手里拥有的最大的财富，他们帮你把产品卖掉，帮你和经销商讨价还价，帮你与消费者做沟通……在具体的业务内容和常规工作程序方面，他们中的一些人甚至具有比你还要丰富的经验，这么好的资源，你为什么不去好好利用呢？即使看在钱的份儿上，你也该让他们的能力得到更充分的发挥啊。

　　障碍四：以为自己可以做得比别人好

　　有些管理者宁可自己做得那么辛苦，也不愿意把工作内容给部下。为什么呢？他们认为，教会部下怎么做，得花上好几个小时；自己做的话，不到半小时就做好

　　了?有那个闲工夫教他们，还不如自己做更爽快些。

　　问题是：难道您就这样一直把所有的事情都自己做吗？尽管现在您自己亲自动手可以做得比别人好，但是您如果能够教会您的员工，您会发现，其实别人也可以做得和您一样好，甚至更好。也许今天您要耽误几个小时来教他们干活，但以后他们会为您节省几十、几百个小时，让您有空做更多的更深入的思考，以促成您在事业上的更大发展。

　　障碍五：害怕削弱自己在组织中的地位

　　这是许多管理者非常害怕的一件事情：如果把自己的权力授予别人的话，会不会因此影响自己对于组织的重要性，从而削弱自己在组织中的地位呢？

　　答案显然是否定的。如果您能够让您的部下能够更加积极、主动地处理问题，您就能充分发挥团队的力量，将任务完成得更多、更快、更好，从而使自己的地位有机会得到进一步的巩固或提升。您将得到一个更有效率的工作团队，并且能够把精力集中在那些值得您全心投入的事情上。

　　障碍六：喜欢与部下争功

　　作为一名管理者，您在很多时候需要扮演“幕后支持者和策划者”的角色，您将很少有机会像从前一样，站在前台接受观众的欢呼。所以，关羽可以过五关斩六将，张飞可以吼断霸王桥，而您只能独自忍受幕后的寂寞。可是您想过没有，正是因为您能够忍受寂寞，关羽、张飞才有勇冠千军的英雄壮举。

　　曾经有一位业务员，非常能干，推销能力很强，曾经在公司连续四年被评为“金牌销售员”。后来，他当了区域销售经理，走上了管理岗位。很快，他与部属之间的冲突也随之而起。为了蝉联“金牌销售员”的荣誉称号，他不仅无法积极地向部属提供帮助，反而抢他们的单。于是，他的员工们只好纷纷离开了他，另寻出路。喜欢与部下争功的管理者，等待他的将是众叛亲离的悲惨结局。

　　障碍七：认为授权会降低灵活性

　　对于一件事而言，事必躬亲确实有利于掌握处理问题的灵活性。可是，对于日理万机的总经理而言，毕竟不可能在同一时间做好几件事情。如果强迫自己面面俱到，就很有些勉为其难了。

　　然而，通过授权把具体的工作分派出去，让自己从一个更高的层面来统帅全局，思路往往会更加灵活，同时也有更多的时间和精力来处理那些棘手的问题和突发性的事件。

　　障碍八：害怕影响员工的正常工作

　　也许您会认为，员工们连现有的工作都做不好，怎么可能承担更大的责任呢？乍一听起来，您似乎是位体恤下情的好领导，但不会有人感激您。俗话说：“强将手下无弱兵。”如果您的员工在工作能力上乏善可陈，问题很可能就出在您的身上。

　　在自然界，老鹰会把自己的孩子逼向悬崖，以迫使胆怯的雏鹰学会飞行。您也应该问问自己，是不是由于您的这种“体恤”，让公司养了一群永远也张不开翅膀的雏鹰？

　　很多优秀员工的流失不是因为您的“体恤”，而是因为没有足够的施展才能的机会。他们不希望自己变成对工作满不在乎的懒人。他们和您一样，渴望接受挑战、面对挑战、战胜挑战、获得成功?但是，如果你不授权的话，他们怎么有机会实现理想呢？

　　障碍九：他们不了解公司的发展规划

　　他们为什么不了解公司的发展规划呢？因为您没有告诉他们，更谈不上去赢得他们的深刻认同。

　　有一些管理者，出于某种可笑的目的，故意把信息管理搞得神神秘秘，以致无法在公司内实现正常的信息传递与分享，甚至连一些重要的信息都不告诉自己的员工。也许，他会觉得，只有这样才能树立管理者的权威，牵着员工们的鼻子走。事实上这些信息对于员工们顺利展开工作十分重要，所以，他的目的往往能够得逞。

　　但是，如果您的员工无法分享公司的发展规划，他们怎么会关心公司的未来呢？公司的发展远景有赖于所有人的努力，特别是那些在其工作领域内堪称专家的员工，更是能为公司实现远景目标铺就道路。您怎么能够把他们和公司的远景规划分开呢？

　　最后，陈登习惯性地来了一段总结陈辞，说：“面对市场竞争的日益激烈，面对公司规模的日益壮大，面对管理活动的日益纷繁芜杂，您一定要学会授权。只有那样，您才能避免琐事缠身，并且可以通过创建一支高绩效的团队，及时有效地完成公司的生产经营任务。”

　　刘备说：“听君一席话，胜读十年书。我知道我该怎么做了。”