napster.txt

P2P NAP的C实现 P2P在网络应用中越来越流行

	If you want napster to share files using 720 instead of 932
	change "1" to "0" at the end of each line in "shared.dat" file.

995	blocked file [SERVER]

	[NAPSTER]

	Format: <binary data>

	This message is used by Napster 10.2+ server to inform
	client that file is blocked. This message is sent in reply
	to command 932.
	Length of data in reply may vary.

3.1  OpenNap and SlavaNap Message Types

The following messages are supported by both OpenNap and SlavaNap servers.
For complete list of OpenNap and SlavaNap commands see "README" file
for OpenNap or SlavaNap.


10112	show server links [CLIENT, SERVER]

	[OPENNAP,SLAVANAP]

	client: no data
	server: <host> <host> <hops>

	This command is used to show information about the links a
	server has to other servers.  The list is terminated by a 10112
	message with no data (0 length).

	Current version of SlavaNap do not support this command completely
	and replies with empty 10112 message. This command is implemented
	by SlavaNap only because AudioGnome uses it.

10115	show server stats [CLIENT, SERVER]

	[OPENNAP,SLAVANAP]

	client: no data
	server: <clients> <servers> <files> <gigs> <channels> <time>
	<uptime> <memory> <numusers>

	This command is used by administrators to get information about the
	state of the server.

	<clients>	number of locally connected clients
	<servers>	number of locally connected servers
	<users>		total number of global users
	<files>		number of files in the db
	<gigs>		total size of all files shared
	<channels>	number of active channels
	<time>		time at which the server was started
	<uptime>	number of seconds of uptime
	<memory>	if debugging is enabled, this will show the memory
			currently in use, otherwise it will be -1
	<numusers>	number of registered users		

10118	display client information statistics [CLIENT, SERVER]

	[OPENNAP,SLAVANAP]

	Available only if OpenNap was compiled with --enable-version-stats or
	"Enable version stats" was enabled in SlavaNap settings menu.

	The server will dump its lists of known clients and the number
	of logins for each.  It does not keep track of unique ips, so this
	just gives a rough estimate on the popularity of various clients.

	(client): empty
	(server): "<version>" <count>

	The server's list is terminated by an empty 10118 message.

10121	who was [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: <nick>

	Displays info about a user that has recently logged out.

10200 	Register user [CLIENT]

	[OPENNAP, SLAVANAP]

	Format: <user> <pass> <email> [ <level> ]

	admin command to force registration of a nickname.
	Note: for SlavaNap <level> is required and shouldn't be "user"

10204	set channel op [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: <channel> <user> [user ...]

	enable <user> to kick/ban users on <channel>

10205	remove channel op [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: <channel> <user> [user ...]

	remove <user> as operator on <channel>

10207	drop channel [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: <channel> [ "<reason>" ]

	marks the specified channel as being user created such that its
	state is not stored in the persistent channels file and will
	disappear once all users part from it.

10208	send message to channel ops [CLIENT, SERVER]

	[OPENNAP,SLAVANAP]

	client: <channel> <message>
	server: <channel> <code> <text>

	client: sends <message> to all operators and mods+ on <channel>
	server: sends message with code <code> and <text> to all operators
		(can be used only by another server) (n/a yet)

10209	change channel mode [CLIENT, SERVER]

	[OPENNAP,SLAVANAP]

	Format: <channel> [mode [mode ...]]

	if specified, [mode] is of the form

		(+|-)STRING

	where STRING is one of

		PRIVATE		- makes the channel not show up in the list
		MODERATED	- only ops and mods+ can speak in public
		TOPIC		- if set, any user may change the topic

		OpenNap only:
		INVITE		- channel is invite only

		SlavaNap only:
		REGISTERED	- if set, channel will not be destroyed after
				  all users will part from it.

	if [mode] is not specified servers returns current mode.

10210	invite user to a channel [CLIENT] (depreciated. use 430 instead)

	[OPENNAP,SLAVANAP]

	Format: <channel> <user>

	This message is OpenNap version of 430 message.

10211	give voice to speak in moderated channel [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: <channel> [user [user ...]]

10212	remove voice to speak in moderated channel [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: <channel> [user [user ...]]

10300	share generic media file [CLIENT]

	[OPENNAP,SLAVANAP]

	Format: "<filename>" <size> <md5> <major-content-type>

	<content-type> is the major MIME type defined for what the data is.
			should be one of:
				audio, video, text, image, application, mp3
			NOTE: mp3 is a separate type here since the original
			nap protocol was designed for sharing only mp3 files.
			"audio" refers to other types of audio files

	MD5 is counted the same way as for command 100.

	Examples:

	"C:\IMAGES\Grand Canyon.jpg" 54187 bc938fdc0ef63772bfbdbf57aabb0860-54187 image
	"\home\drscholl\src\opennap-0.11.tar.gz" 102161 51c07734811a26853b1a2a87b67c68a1-102161 application


3.  MD5

All MP3 files are hashed using the first 300,032 bytes of the file.
WMA files are not hashed and Napster sends "WMA-FILE" instead of MD5 for .wma

The current method seems to be: skip id3v2, seek to frame sync and hash.

Note: the linux nap client (versions 0.7 - 0.9) hash exactly 300,000
bytes, which is NOT what the official windows client does.

Correct format for MD5 is something like "58dc354f81bf37b050799ead7ca8d3bc-5333975"
where "58dc354f81bf37b050799ead7ca8d3bc" is MD5 hash and "5333975" is file
length - length of ID3 tags (v1 and v2).

Some clients ignore MD5 or send incorrect values. For example, WinMX sends MD5
without file size and FileNavigator sends "AAAAAA" (32 "A" characters) instead
of MD5. OpenNap and SlavaNap ignore md5 and do not support it by default
unless recompiled using special options.


5.  Client-Client Protocol

File transfer occur directly between clients without passing through the
server.  There are four transfer modes, upload, download, firewalled upload,
firewalled download.  The normal method of transfer is that the client
wishing to download a file makes a TCP connection to the client holding the
file on their data port.  However, in the case where the client sharing the
file is behind a firewall, it is necessary for them to "push" the data by
making a TCP connection to the downloader's data port.


5.1  Normal Downloading

Regardless of which mode, the downloading client will first issue either a 
search(200) or browse(211) command to the server.  This returns a list of
files and information on the client sharin the file.  To request a download,
a get(203) request is sent to the server.  The server will respond with
a get ack(204) containing more detailed information.

This is the point at which the different methods diverge.  If the 204 get
ack says that the remote clients data port is 0, you must send a 500 request
to the server requesting that the remote client send the data to you.  In
this case you wait for the remote client to connect to your own data port.

In the case where the sharing client is not firewalled, you make a TCP
connection to the data port specified in the 204 message from the server.
The remote client should accept the connection and immediately send one
ASCII char, `1' (ASCII 49).  Once you read this char, you send a request
for the file you wish to download.  First send the string "GET" in a single
packet, then send
	<mynick> "<filename>" <offset>
where <mynick> is your napster user name, <filename> is the file you wish to
download, and <offset> if the byte offst in the file to begin the transfer
at (if you are downloading for the first time, and not resuming a prior
transfer, you should uses 0 to start at the beginning of the file).

The remote client will then return the file size, or an error message such
as "INVALID REQUEST" or "FILE NOT SHARED".  Note that the file size is not
terminated in any special way, and the best way to figure out the size is to
keep reading until you hit a character that is not a digit (it will usually
be 0xff which is the start of the MP3 frame sync header, but if a ID3v2
tag is present it might look different).  Immediately following the file
size is where the data stream for the file begins.

Once the data transfer is initiated, the downloader should notify the server
that they are downloading a file by sending the 218 message.  Once the
transfer is complete, you send a 219 message to indicate you have finished
the download.  Note that this is cummalitive, so that if you are downloading
multiple files, you send one 218/219 pair for EACH concurrent download--this
is how the server knows how many transfers you have going on.  Likewise,
the uploader should send one 220 messge for each upload, and one 221 when
each upload has finished.


5.2  Firwalled Downloading

As described above, when the file needs to be pushed from a client behind a
firewall, the downloader sends a 500 message to the server.  This causes a
501 message to be sent to the uploader, which is similar to the 204 message
for a normal download.

Once the uploader receives the 501 message from the server, they should make
a TCP connection to the downloader's data port (given in the 501 message).
Upon connection, the downloader's client will sent one byte, the ASCII
character `1'.  The uploader should then send the string "SEND" in a single
packet, and then the information:
	<mynick> "<filename>" <size>
where <mynick> is the uploader's napster user name, <filename> is the file
being sent, and <size> is the size of the file in bytes.

Upon receipt, the downloading client will either send the byte offset at
whcih the transfer should start, or an error message such as
"INVALID REQUEST".  The byte offset should be sent as a single packet
in plain ASCII digits.  Just as with above in section 5.1, a 0 byte offset
indicates the transfer should begin at the start of the file. If you are
writing a nap client and have trouble with firewalled downloading first
check if you are sending offset in ASCII (this is the most common error)

Each client should notify the server that they are uploading or downloading
with the 218/219 (downloading) or 220/221 (uploading) command pairs (see
section 5.1 for more detailed information).


5.3 Client to Client Browsing

Napster 2.0 Beta 8 adds a feature which allows direct client-to-client
browsing of file lists. Direct browsing is supported by Napster Beta 8-9.6
From Napster 2.0 Beta 10 direct browsing is disabled. To request a browse,
a client uses the
	640 <nick>
command.  The server then sends a
	640 <requester>
to the client which is getting browsed with the nick of the client that is
requesting the browse.  If the client accepts the browse request, it sends
back a
	641 <requestor>
to the server with the nick of the client requesting the browse.  The
server then sends a
	641 <nick> <ip> <port>
to the requesting client.  In the case of an error, the server will send a 642
command in response to the 640 command.

The browsing client then makes a TCP conection to the remote client's data
port.  After getting the "1" character, the browsing client sends a
	GETLIST
At which point the remote client sends its nick followed by a linefeed (\n)
by itself in a single packet (ie, one write() call)
	<nick> LF
followed by the list of files being shared (the format being the same as
the data of the "share" command).  Each line is terminated by a linefeed char.
At the end of the list, an additional linefeed char is sent and then the
client closes the connection.

In the case that the remote client is firewalled, the browse list will have to
be pushed to the requesting client.  The remote client makes a TCP connection
to the requesting client, then sends
	SENDLIST <nick>\n
followed by the list of files, as with the "GETLIST" command response.


6.  Napigator protocol specification

Napigator server runs on "stat.napigator.com" port 8890.

In this section when I use word "client" it means OpenNap or SlavaNap
server and when I use word "server" it means Napigator server.

Message format for server: 

    <id> [<text>] \r\n

    <id> is message code in ASCII
    <text> is message text. There is a space (" ") chacter between <id> and <text>.
    Every line is terminated with \r\n (0x0D,0x0A) sequence. Strings should NOT be
    quoted.

Message format for client:

   <command> [<text>] \r\n

   <command> is text command (like USER or PASS)
   Every line is terminated with \r\n (0x0D,0x0A) sequence. String should NOT be
   quoted.

When client connects to server, server should send command 220. Client replies
with "USER". Then server sends command 300. Client replies with "PASS". If name
and password are correct server replies with 201.

Connection should be kept alive. Every 60 seconds (or any other period) client
sends "STATS" message.

Server messages:

	200	stats updated.

		No reply required.

	201	login ok.

		Format: 201 <message>

		Login sequence is complete.
		Client should reply with "IPPORT".

	220	request user name.
		
		Format: 220 <salt_string>

		Salt string used by client to encode password.
		Client should reply with "USER" message.

	221	login error.

		Format: 221 <error>

		Client should disconnect after receiving this message.

	300	password request.

		Client should reply with "PASS" command.

	other messages: something is wrong and client should disconnect.

Client messages:

	USER	send user name

		Format: USER <user_name>

	PASS	send user pass

		Format: PASS <encoded_password>

		password is encoded with MD5. Before encoding password you should
		put salt string (that you have received with 220 message) before password.

		Example:

		If your password is "qwerty" and you have received "1234" as salt string,
		encoded password will be MD5("1234qwerty");.

		Note: MD5 letters should be in upper case.

	IPPORT	send server address.

		Format: <hostname> <ip> <port>

		Note: this command should be sent only when login sequence is completed.
		
	STATS	update server stats.

		Format: <hostname> <users> <files> 0 <size> 0

		<hostname> is name of your server (ex. cyberalien.servemp3.com)
		<users> is number of connected users (ASCII)
		<files> is number of shared files (ASCII)
		<size> is size of files in Gb (ASCII)

		Note: this command cannot be used before login sequence is completed.

If you have created Napigator-compatible server mail me at mailto:[e-mail]
and I'll add support for your server to SlavaNap.
To add you server support to OpenNap mail Dr.Scholl at mailto:[e-mail]


7.  Where to get more help?

Join the napdev mailing list by sending email to mailto:[e-mail]
or by visiting the community page http://www.onelist.com/community/napdev/.
This list is designed for open source nap developers to share information
about the specification or applications.

Latest version of this document is available at http://slavanap2.sourceforge.net/nap.txt
Original document is available at http://opennap.sourceforge.net/napster.txt

Some implementations of this protocol (servers and clients) come with
source code. Visit http://slavanap2.sourceforge.net or http://opennap.sourceforge.net
for more information.


8.  Servers compatible with this protocol:

	For Linux:  O