Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/pdfrfc/rfc996.txt.pdf Дата изменения: Wed Mar 27 23:53:42 2002 Дата индексирования: Tue Oct 2 16:40:37 2012 Кодировка:

Network Working Group Request for Comments: 996

D.L. Mills University of Delaware February 1987

Statistics Server STATUS OF THIS MEMO This RFC specifies a standard for the ARPA Internet community. Hosts and gateways on the DARPA Internet that choose to implement a remote statistics monitoring facility may use this protocol to send statistics data upon request to a monitoring center or debugging host. Distribution of this memo is unlimited. DISCUSSION Many host and gateway implementations include a facility which records traffic statistics, such as packet counters, error counters and significant event counters for debugging and performance evluation. Simple data-access and formatting programs can be used to display these statistics along with the status of connections, etc. Several operating systems, including the various Unix systems and Fuzzball systems, already provide extensive facilities to capture and display these data for local users and/or operators. In many instances it is highly useful to observe statistics data on remote hosts and gateways from a monitoring center or debugging host. Indeed, several protocols have been implemented and used expressly for this purpose [1-6]. In many cases the data can be retrieved using conventional services such as remote login or even file transfer. However, use of these heavyweight mechanisms is awkward and intrusive if conducted on a regular, frequent basis and may involve substantial intrusion in the operating system if retrofitted to existing systems. The Statistics Server (STATSRV) protocol is intended as a lightweight mechanism similar in spirit to NETSTAT [7] and complementary to it. STATSRV is designed to capture statistics data with minimal intrusion on existing systems or networks. It is intended for use with existing hosts and gateways primarily for casual monitoring and debugging purposes. It is not intended as a full-function monitoring protocol [1,5,6] providing detailed, standardized reports suitable for machine analysis, for example, but could be useful in exploratory development leading to enduring systems of this type. The STATSRV model is based on the native host command language used for statistics monitoring and display. The client sends a nullterminated ASCII command to the server, which then responds with a null-terminated ASCII response suitable for a printer or CRT display. Although in principle STATSRV could be used over TCP, it is less intrusive and more efficient to use it over UDP. In the case of UDP,

D. L. Mills

[Page 1]


RFC 996

February 1987

commands and responses must fit into a single 576-octet IP datagram. In both UDP and TCP the assigned port number is 133 (decimal). As is conventional (NETSTAT, FINGER, authentication in password or other EXAMPLE The Fuzzball system includes many local commands to display internal data structures, including one that produces the following billboard for each network device, in this case "dm0" on host "udel2.udel.edu": Process type: 000027 options: 040000 Subnet: DMV status: 376 hello: 15 timeout: 2000 Foreign address: [192.5.39.87] max size: 576 Input packets 3645 Output packets 3690 bad format 0 ICMP msgs 0 bad checksum 0 Input errors 0 returned 0 Output errors 0 dropped 2 No buffer 0 HELLO msgs 2286 Preempted 0 The same billboard is returned as a null-terminated ASCII string in a UDP datagram by sending the null-terminated ASCII command "dm0" in a UDP datagram to the host. Similar billboards can be produced for most processes in the system. Unix programs and shell scripts have been built which send commands like these to selected hosts on a periodic basis in order to construct a simple, ad-hoc monitoring facility. REFERENCES [1] Flood Page, D.,"Gateway Monitoring Protocol", DARPA Network Working Group Report IEN-131, Bolt Beranek and Newman, February 1980. Flood Page, D., "The CMCC Terminal Process", DARPA Network Working Group Report IEN-132, Bolt Beranek and Newman, February 1980. Flood Page, D., "CMCC Performance Measurement Message Formats", DARPA Network Working Group Report IEN-157, Bolt Beranek and Newman, September 1980. Jones, R.G., " A Proposal for Simple Measurement Support for Users", DARPA Network Working Group Report IEN-161, University College London, November 1980. in other lightweight services of this type etc.), there is no provision for access control or STATSRV. If necessary, each command could include a mechanism to discourage casual abuse.

[2]

[3]

[4]

D. L. Mills

[Page 2]


RFC 996

February 1987

[5]

Littauer, B.M., A.J. Huang and R.M. Hinden," A Host Monitoring Protocol", DARPA Network Working Group Report IEN-197, Bolt Beranek and Newman, September 1981. Hinden, R.M.," A Host Monitoring Protocol", DARPA Network Working Group Report RFC-869, BBN Communications Corporation, December 1983. Reynolds, J.K., and J. Postel, "Assigned Numbers", DARPA Network Working Group Report RFC-990, USC Information Sciences Institute, November 1986.

[6]

[7]

D. L. Mills

[Page 3]