NETBUGGER3
A tool for testing network protocols when the remote system is not yet operational.
Kampe, M., "NETBUGGER3", RFC 162, DOI 10.17487/RFC0162, May 1971, <https://www.rfc-editor.org/info/rfc162>.
@misc{rfc162,
series = {Request for Comments},
number = 162,
howpublished = {RFC 162},
publisher = {RFC Editor},
doi = {10.17487/RFC0162},
url = {https://www.rfc-editor.org/info/rfc162},
author = {M. Kampe},
title = {{NETBUGGER3}},
pagetotal = 2,
year = 1971,
month = may,
} RFC text
Network Working Group M. Kampe
Request for Comments: 162 UCLA-NMC
NIC #6774 Computer Science
Categories: C.2, C.3, D.1, D.2, D.3 22 May 1971
Updates: None
Obsoletes: None
NETBUGGER3
NETBUGGER3 is a third level program for the debugging of second and
third level programs, experimentation with and simulation of third
level protocols.
We were writing an RJE FILENET to interact with UCLA-CCN, and
discovered that they (UCLA-CCN) wouldn't be up for a few months. We
needed a program that would simulate CCN, so that we could interact
with it and debug our FILENET. It occurred to me that all over the
network, people had similar problems, i.e., they couldn't debug
programs because the intended server wasn't up. And so I started to
write a third level debugger-simulater.
With NETBUGGER3 the user can easily issue RTSs, STRs, and LISTENs,
interrogate the status of connections, receive and display NCP-USER
events and transmit and receive data over as many as twelve
connections (per copy of program running). Received data can be
displayed in ASCII, EBCDIC on HEX. The user can, of course,
originate data for transmission in the same forms. NETBUGGER3 can be
initiator, receiver and/or intermediate in connections.
An example of how NETBUGGER3 could be of use to other hosts on the
Net follows.
Host X has a special third level Filenet to debug. The host they
plan to interact with won't be up for several months. Host X can
arrange with us to interact with NETBUGGER3, which will simulate the
proposed third level protocol and transactions.
An alternate possibility is for Host X to use his Telnet to enter our
system and start NETBUGGER3 himself. He can then be running
NETBUGGER3 on one console and his filenet on another.
An alternate possibility is for Host X to use his Telnet to enter our
system and start NETBUGGER3 himself. He can then be running
NETBUGGER3 on one console and his filenet on another.
Then, later on when the other server Host is up, NETBUGGER3 can be
used an intermediate between Host X and his serving host. Every
message from Host X to server and vice versa can be displayed,
examined and, if necessary, edited as it passes through the
NETBUGGER3 console, thus making possible the debugging and
measurements.
This is only one example. If you are interested in using, receiving,
documentation, making suggestions or anything else regarding
NETBUGGER3, please contact the Network liaison at UCLA - NMC.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alison De La Cruz 12/00]
AI ELI5
On this page
§1The Problem and the Tool
The UCLA Network Measurement Center faced a familiar problem: they were writing an RJE (remote job entry) FILENET protocol to interact with UCLA-CCN, but that system would not be operational for several months. They needed a program that could simulate CCN so they could test their protocol without waiting.
Mark Kampe realized that many sites on the network had the same problem: they could not debug client programs because the intended server was not yet running. So he started writing NETBUGGER3, a third-level debugger and simulator that could stand in for any remote system.
A group at UCLA was building a program to talk to a computer that would not be ready for months. They wrote NETBUGGER3 to pretend to be that computer, so they could test their code right away.
§2What NETBUGGER3 Can Do
NETBUGGER3 runs at UCLA-NMC and lets a user issue Network Control Program (NCP) commands like RTS (request to send), STR (start transmit request) and LISTEN. The user can check the status of connections, receive and display NCP-USER events, and exchange data over up to twelve simultaneous connections.
Received data can be displayed in ASCII, EBCDIC or hexadecimal. The user can originate data for transmission in the same formats. NETBUGGER3 can act as the initiator, receiver or intermediate in network connections, making it flexible enough to simulate a wide range of protocols.
NETBUGGER3 lets someone send and receive messages, open and close connections, and see exactly what data is flowing. A person at UCLA can watch and control what the pretend server does.
§3How Other Sites Used It
Other hosts on the network could arrange with UCLA to test their protocols against NETBUGGER3. Alternatively, a host could use Telnet to log into the UCLA system and start NETBUGGER3 themselves, running it on one console while testing their protocol implementation on another.
Later, when the actual remote server became operational, NETBUGGER3 could be used as an intermediate proxy between the client and server, allowing engineers to monitor and debug the real communication by viewing and editing messages as they passed through.
People from other computers could call UCLA over the network and start NETBUGGER3 to test their protocol. Or later, NETBUGGER3 could sit between the real computers and let someone see what they are saying to each other.