Index Journeys
RFC 162 UNKNOWN TESTING · PROTOCOLS

NETBUGGER3

A network tool for testing protocols when a remote server is unavailable.

On rfc-editor.org ↗
PUBLISHED
May 1971
AUTHORS
M. Kampe
STREAM
Legacy
CONNECTIONS PER RUNNING COPY
Up to twelve
DOI
10.17487/RFC0162
ERRATA
Reported errata

RFC text

Original text · RFC Editor View on rfc-editor.org ↗ 
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]

ISO Plain Language

On this page
PROBLEMUCLA needed to test a file-transfer program before the remote system it would communicate with was available.
MECHANISMNETBUGGER3 lets a user issue NCP commands, inspect connections and exchange data while simulating or mediating a third-level protocol.
TESTING TOOLOther network hosts could arrange to use it to debug programs or inspect messages between a client and a real server.

§1Why NETBUGGER3 Was Written

UCLA was writing an RJE FILENET program to interact with UCLA-CCN, but that system would not be available for several months. The author needed a way to simulate CCN and realized other network sites faced similar delays when their intended servers were not running.

NETBUGGER3 is described as a third-level program for debugging second- and third-level programs and experimenting with or simulating third-level protocols.

A program can be hard to test if the computer it needs is not running yet. NETBUGGER3 provides a way to test against a simulated service instead of waiting.

§2Commands and Data Inspection

A user can issue RTS, STR and LISTEN commands, check connection status, receive and display NCP-USER events, and send or receive data over as many as twelve connections per running copy. Data can be displayed or entered as ASCII, EBCDIC or hexadecimal.

NETBUGGER3 can act as the initiator, receiver or an intermediate party in connections.

NETBUGGER3 can open and monitor connections, and users can inspect or enter data in several encodings. It can take different roles in a connection.

§3Testing at Other Sites

A host developing a special third-level protocol could arrange with UCLA to interact with NETBUGGER3 while its intended server was unavailable. Alternatively, a user could log in to the UCLA system with Telnet and run the debugger on one console while running the program under test on another.

After the real server became available, NETBUGGER3 could act as an intermediary. The user could view, examine and, if needed, edit messages passing between the host and server.

Other sites could use UCLA's program before their intended server was ready. Later, it could sit between real systems so a developer could examine their messages.