NetPlorer readme:

NetPlorer is a simple text protocol utility.
There are different services that you can access using NetPlorer such
as POP3, SMTP and others. All of the commands for these protocols are
text strings (integers are transmiited as strings etc...).
NetPlorer supports 2 transport protocols: TCP and UDP. Transport protocol
is a protocol on the top of which any text protocol runs. Some services
such as Quake 3 server information is available using UDP only. Some are
available using TCP or UDP, in which case TCP will be used because it is
a reliable protocol.

What does that mean to you and what can you do with NetPlorer:
When you start netplorer, displays a simple user interface that lets you
do 3 things:
1) conect to a remote host on a certain port
2) send a command using that connection and receive a reply
3) look up help on the commands selected from command selection.

Once NetPlorer is running I recommend selecting a protocol that you
will need. This automatically will select a desired port, desired transport
protocol and set up all of the commands available to the user in the
commands pull down menu. This will allow you to use HELP button to display
help on commands that you have selected.

At this time you can change default port # or connect to the server as it
is. Just type an address or IP into address field and press connect.
If connection is successful you will see NetPlorer - Connected on the
title bar and the button's caption will change from connect to disconnect.

After connecting successfuly, you can send any text command to the server
and see how it will reply.


Example:
This is one of the USEFUL things you can do with NetPlorer:
Imagine that you friend sent you 3 five meg files using e-mail.
You open up your favorite e-mail client (such as Outlook)and start
downloading.  It downloads 2 of the 3 messages (10 megs) and crashes
just when it starts downloading the third. Well, you say, not a
problem. You restart your mail client and connect to your POP3 server
again, just to find out that your e-mail client starts downloading all
3 messages again! This is a bug in the client and a feature in the
server. What happens is your server will not delete the messages if the
client didn't send QUIT command at the end of the session. Client on the
other side did not bother to check and save UIDLs (Unique ID) of the
messages so it starts to download them again.
Here is how NetPlorer can fix it:
Connect to your POP3 server.
Identify yourself ( USER yourusername )
Send your password (PASS your password )
at this time you will be able to list and delete your messages off the
server. To do that:
issue a command (LIST)
this will show you all of your messages. Select which one you want to
delete and issue comamnd (DELE message#) - you can do this several times
Once you are done, send (QUIT) to the server and you will see that
the connection was closed.
Now when you use your e-mail client, it will not download those long
messages that you already have.


Another useful feature is ident. simply connect to remote host using any
of your existing programs (for example Netscape) then do netstat on 
local machine to find out the local port #. After that simply conect to
remote host using ident and supply locan adn remote port #s
for example: (80,1115) and remote will show you under what userid the
deamon (server) is running.


But this is only the beginning.
NetPlorer supports ANY text based protocol. You can type any commands
and connect to any server you want. The only difference is that help
will not be available to you and you have to know all of the commands
and port # for that protocol. If the transport protocol is TCP you can
connect to that server using telnet, but if it's UDP, you can only use
the NetPlorer!
In addition, adding a protocol to NetPlorer is a snap. Just edit the
procs.cpp file and add needed protocol name, and commands. Recompile the
NetPlorer and they will be available to you!
if you don't know how to do that, send me an e-mail and I will do it for
you : amakushk@ic.sunysb.edu


NetPlorer also has a "Scan" feature. What it does is finds out automatically
for you which services are running on a remote machine and on which port.
to use this feature, just type in the correct IP/Address, specify the
starting port and click scan.
Scan only supports TCP/IP connections. It's limited by the way scanning
is done. For each scan, a full TCP/IP connection is created and then
teared down. This is slow and takes a long time. As an alternative one
can do partial conenction scanning but under NT a supervisor's priveleges
are needed. It's also possible to open several connections at once to
speed up scanning, but Netplorer is not intended to be a full blown
scanner and therefore will not implement this feature.
Anyway this is what you need to do to scan a range of port numbers:
Type in the IP/Address in the address field. Enter the starting port #
in the port field and press scan :) that's it...


BUGS and future features:
* Currently connections are closed by closesocket() and sometimes leave
  sockets hanging in time_wait state. I will fix it when I find out where
  SD_BOTH used in shutdown(s,SD_BOTH) is declared (not in windows.h)
* allow user to specify the # of lines kept in the scroll back buffer.
  for now there is a fixed amount imposed by the system, after which the
  buffer will not display any more info and has to be cleared manually by
  pressing clear button.
* Allow user to submit command by pressing enter while in command edit box.
  I don't know how to do that since  COMBOBOX does not
  save enter chars in it's buffer so the only way I see is to use
  WM_KEYDOWN and then figure out where the focus is.. but it's complicated
  anyone has any ideas?
* Allow user to type the commands in the large output window directly.
  This will requre processing of every key entered in output window
  since it seems to me that EDIT control does not send the BN_CLICKED
  messages when enter is pressed but I think it's supposed to.
* Add accelerators for buttons
* Add tab order ( I set the WS_TABSTOP but it doesn't work) if anyone
  knows why, please let me know.
* Make IP/address as a pull down menu. every time you connect or scan,
  current selection (new entry only)will temperarily be added to the list.


CopyLeft Andrey Makushkin 1999
By using this program you agree to the following:
The author of the program is not responsible for any damage that the program
might cause. The author is also not responsible for any illegal actions
taken by the user.

################### Below is some info I used while programming ########

The text in an edit control is stored as one long character string. Each
carriage return <CR> is stored as ASCII code (0x0D,0x0A). If a line wraps
because the next word won't fit on the same line, a <CR> is inserted. A NULL
character is inserted only at the end of the last line of text.
Getting the contents of an edit control--We must extract it line by line.
To do this:
1. Send the control an EM_GETLINECOUNT message to determine the number of 
   lines stored.2. For each line, send the following messages:
    EM_GETLINE to copy the line into a buffer;
    EM_LINEINDEX to determine character position of the start of the next line;
    EM_LINELENGTH to get the length of the line;
All this is done in response to a WM_COMMAND message when the user selects
the menu item "Get Text" (IDM_GET). The extracted text is then written line
by line to the main window using TextOut() and the line number to positionit.
Note that if we resize or cover/uncover part of the text extracted and
displayed in the main window, it does not reappear, since we're not
handling WM_PAINT messages for the main window. The text in the edit window
does reappear because that handling is built into the edit control.

#########################################################
214-HELO <hostname>
214-	Introduce yourself.
214-RSET
214-	Resets the system.
214-EXPN <recipient>
214-	Expand an address.  If the address indicates a mailing
214-	list, return the contents of that list.
214-EHLO <hostname>
214-	Introduce yourself, and request extended SMTP mode.
214-VERB
214-	Go into verbose mode.  This sends 0xy responses that are
214-	are not RFC821 standard (but should be)  They are recognized
214-	by humans and other sendmail implementations.
214-NOOP
214-	Do nothing.
214-MAIL FROM: <sender>
214-	Specifies the sender.
214-QUIT
214-	Exit sendmail (SMTP).
214-RCPT TO: <recipient>
214-	Specifies the recipient.  Can be used any number of times.
214-HELP [ <topic> ]
214-	The HELP command gives help info.
214-VRFY <recipient>
214-	Verify an address.  If you want to see what it aliases
214-	to, use EXPN instead.
214-DATA
214-	Following text is collected as the message.
214-	End with a single dot.
#######################################################################
Quake 3 Server commands howto.

The Quake 3 Arena server exclusively uses UDP packets for all transmission.  Specifically, it uses what we define as "Out Of Band" packets (OOB), or connectionless packet.  That is, the first four bytes of the packet make up the serial number of the packet (in a series of two 16 bit words), and whether or not it is reliably sent (reliable packets set the high bit of the word), but when an OOB packet it sent, the first four bytes are marked as 0xff, followed by the command, which is in ASCII.
The server normally responds on port 27960, but this is user configurable with the "net_port" cvar.  The server will automatically increment from 27960 when a second instance of the application is started to allow up to four servers on a single machine.
Because we're using UDP you are not guaranteed to get data back, so you need to set up your code to use the appropriate time outs.  The value 65507 is the maximum possible packet size receivable through a datagram, although actual transport through the Internet is somewhat more limiting.
The commands accepted as OOB packets are as follows:

getstatus
getinfo
getchallenge
connect
rcon

Any other command will result in the error "bad connectionless packet from xxxxx".
"getstatus" responds with all the info that qplug or qspy can see about the server and all connected players.  Used for getting detailed information after the simple info query.  It is sent along with a challenge string.  The server will respond with a "getstatusResponse" packet.
"getinfo" responds with a short info message that should be enough to determine if a user is interested in a server to do a full status.  It is also sent with a challenge string.
"getchallenge" returns a challenge number that can be used in a subsequent connectResponse command.  We do this to prevent denial of service attacks that flood the server with invalid connection IPs.  With a challenge, they must give a valid IP address.  The server will respond with a "challengeResponse" packet.
"connect" is the first step in a client connecting to a server.  You send the "connect" string followed by the infoString containing the protocol version of the client, the qport, the challenge string (obtained via getchallenge), and the userinfo.
"rcon" is a remote command to the server.  It's sent as "rcon" followed by the server password, followed by the command string to be executed.

Format of packets.
When you send a command like "getstatus" or "getinfo", you should add a challenge parameter to your packet that the server needs to relay back to you.  We do this in order to stop ghost servers appearing which do nothing more than send ghost heartbeats to a master server, you should query and check a server with a challenge before accepting it.  A typical challenge is a random word ASCII string, remember that this adds to your packet size on sending and receiving.
Arguments in the packet string are separated by whitespace.  So to send in a getstatus command with a challenge string you would use a string like "getstatus justchecking", where "getstatus" is the ASCII text following the OOB packet header, and "justchecking" is the challenge string.
To send a request, with a challenge, to a server you could use this, the java class publicServer contains information on the server such as it's port, address, challenge string, and tracks the response from the server as well.
The infoString format
When the server responds to this command, it will send an OOB packet back with a series of tokens, separated by back slashes ("\"s) that make up the response, we call this the "infoString" format, and it's important because a lot of client/server communication is sent using this method of partitioning strings.  InfoStrings are normally completely quoted (i.e. they have a " at the beginning and at the end) to make them into a single argument.

In the case of the "getstatus" or "getinfo" one of these responses will be the string "challenge", which needs to exactly match the challenge string you sent to the server in order for the response to be valid.
Connection

A client connects to the server through the OOB "connect" packet in the format outlined above.  This consists of a connect string followed by an infoString which contains of /at least/ the following tokens:
"protocol" - the version of the client.  This is a check to make sure we match between the server and the client.  Mismatched protocols may not connect and the connection is terminated if they do not match.
"challenge" - as outlined above, this is the string that the client gets back from a getChallenge request.
"port" - which qport should the server use when addressing this client.  A qport is a separate address from the actual UDP port that the client/server uses, and can be used to resolve issues when we have multiple clients on a single dynamic IP address.
