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

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.