I noticed that many of the clients attempt to connect
directly to the napster metaserver (208.184.216.223).  I
overheard yesterday on #napster that a better way to do this
is to resolve server.napster.com.  Makes sense since if they
change the ip address of the metaserver, they don't want their
clients to break.

In case you don't remember how, this code shows how to do a dns
lookup:

#include <netdb.h>
#include <netinet/in.h>

int
nametoip (const char *cp, unsigned long *ip)
{
     struct hostent *he;

     he = gethostbyname (cp);
     if (!he)
         return -1;
     *ip = ntohl(*((unsigned long *) he->h_addr_list[0]));
     endhostent ();
     return 0;
}

it would be nice if the metaserver to connect to were a configurable
parameter in the clients.  you probably want to hardcode the ip for
server.napster.com, but allow a user to specify another one to connect to.
as it is now i have to go edit each client i test.  :-)

work on the server is progressing very well.  i have implemented most all of
the commands that the nap client supports, and yesterday i was able to
successfully do a search and transfer files between two clients.  what i
will probably do is release the first alpha version of the server soon and
then put up a testing server to iron out the bugs in the code.  now someone
gets to implement the messaging part so we i can test that too...

fixed an error in the search response section and added a few more examples.
napster messages
================

by drscholl@...
December 7, 1999

0.  Forward

This is meant to be an open specification.  If you find errors or know of
additional functionality not described hereafter, please send me email.  It
benefits the entire community to have a complete and accurate protocol
specification.  Not only does it allow for clients to be developed for any
platform, but also decreases the strain on the server having to parse out
bad client messages.

Disclaimer: the following information was gathered by analyzing the protocol
between the linux nap client and may not resemble the official windows client
protocol.

1.  Client-Server protocol

each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 bytes each.  <length> specifies the length in
bytes of the <data> portion of the message.  Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first).  For
example, in the C language you would encode the number 1 as
	 const unsigned char num[2] = { 0x01, 0x00 };
and 256 would be encoded as
	 const unsigned char num[2] = { 0x00, 0x01 };

Note that in many cases, strings are passed as double-quoted entries.  For
example, filenames and client id strings are always sent as
	 "random band - generic cowboy song.mp3"
or
	 "nap v0.8"

Some additional information about use of quotes inside of quotes:
> The answer is, no, it doesn't do escaping of quotes.  If you try searching
> for the phrase 'a "quoted" string' on the windows client, you get no songs
> found, and "invalid search request" printed in yellow in your console
> window.  (don't know what code that is, sorry.)
>
> and no wonder-- a little birdie told me that the client sends this:
>
> FILENAME CONTAINS "a "quoted" string" MAX_RESULTS 100

[contributed by Ben Byer <bbyer@...>.  -ed]

Note that unlike the IRC protocol, each line does NOT end in \r\n.  The
<length> field specifies exactly how much data you should read.

2.  Message Types

The following section describes the format of the <data> section for each
specific message type.  Each field is denoted with <>.  The fields in a
message are separated by a single space character (ASCII 32).  Where
appropriate, examples of the <data> section for each message are given.

<type> can be one of the following (converted to big-endian):

0 error message

	 <message>

2 client login message

	 <username> <password> <port> <client-info> <link-type>

	 <port> is the port the client is listening on for data transfer
	 <client-info> is a string containing the client version info
	 <link-type> is an integer indicating the client's bandwidth
		 0  unknown
		 1  14.4 kbps
		 2  28.8 kpbs
		 3  33.6 kbps
		 4  56.7 kbps
		 5  64K ISDN
		 6  128K ISDN
		 7  Cable
		 8  DSL
		 9  T1
		 10 T3 or greater

	 Example:

	 foo badpass 6699 "nap v0.8" 3

3 login ack

	 <email>

	 the server sends this message to the client after a succesful
	 login (2).  If the nick is registered, the <email> address given at
	 registration time is returned.  If the nick is not registered, a
	 dummy value is returned.

6 alternate login format

	 this message is used when logging in for the first time after
	 registering (0x07) a nick

	 <nick> <pass> <port> <client-info> <linkspeed> <email-address>

	 note: this message is similar to the 0x02 message, with the addition
	 of <email-address> on the end

	 Example:

	 foo foo 6699 "nap v0.8" 3 email@...

7 client registration message

	 <nick>

	 this message is sent to create an account

	 response to this message is one of 8, 9 or 10

8 registration success

	 the server sends this when the clients request to register a new
	 nickname has succeeded.

9 nickname already registered

	 the server sends this message when the nickname the client has
	 requested has already been registered by another user

10 invalid nickname

	 this server sends this message when the client attempts register
	 an invalid nickname [what defines an invalid nickname? -ed]

100 client notification of shared file

	 <filename> <md5> <size> <bitrate> <frequency> <time>

	 <md5> see section "MD5"
	 <size> is bytes
	 <bitrate> is kbps
	 <frequency> is hz
	 <time> is seconds

	 Example:

	 "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128
44100 60

200 client search request

     [FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
"song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
<compare> "<freq>"]

         The artist name and the song name are, obviously, treated
                 the same by the server; confirm this for yourself
                 on the windows client.

         max is a number; if it is greater than 100, the server will
                 only return 100 results.

         <compare> is one of the following:
                 "AT LEAST" "AT BEST" "EQUAL TO"

         <link-type> see 0x02 (client login) for a description

         <br> is a number, in kbps

         <freq> is a sample frequency, in Hz

         The windows client filters by ping time inside the client.
                 It pretty much has to, and it's easy to see the
                 result by setting ping time to at best 100 ms or
                 so, and max search terms to 50.  You'll get back
                 like 3 results, but the client will still tell you
                 that it found "50 results".

         Examples:
                 FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
                          CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"

                 MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
                         "EQUAL TO" 10

	 [Thanks to Ben Byer <bbyer@...> for this contribution.  -ed]

201 server response to search

	 <filename> <md5> <size> <bitrate> <frequency> <length> <nick> <ip> <link-type>

	 <md5> see secton "MD5"
	 <size> is file size in bytes
	 <bitrate> is mp3 bit rate in kbps
	 <frequency> is sample rate in hz
	 <length> is the play length of the mp3 in seconds
	 <nick> the person sharing the file
	 <ip> is an unsigned long integer representing the ip address of the
		 user with this file
	 <link-type> see message client login (2) message for a description

	 Example:

	 "random band - random song.mp3" 7d733c1e7419674744768db71bff8bcd 2558199 128
44100 159 lefty 3437166285 4

202 end of search response from server (0 byte data section)

203 download request

	 <nick> <filename>

	 client requests to download <filename> from <nick>

	 Example:

	 mred "C:\Program Files\Napster\generic cowboy song.mp3"

204 download ack

	 <nick> <ip> <port> <filename> <md5> <linespeed>

	 server sends this message in response to a 203 request.

	 <nick> is the user who has the file
	 <ip> is an unsigned long integer representing the ip address
	 <port> is the port <nick> is listening on
	 <filename> is the file to retrieve
	 <md5> is the md5 sum
	 <linespeed> is the user's connection speed (see login(2))

	 Example:

	 lefty 4877911892 6699 "generic band - generic song.mp3"
10fe9e623b1962da85eea61df7ac1f69 3

205 private message to/from another user

	 <nick> <message>

	 note the same type is used for a client sending a msg or recieving one

	 [Commentary: this message causes problems if you consider linking
	 servers together.  With the current one server situation, the server
	 just rewrites the message it receives with the name of the client that
	 sent it and passes it to the recipient client.  However, in the case
	 where the recipient and sender are not on the same server, there is
	 loss of information without encapsulating it.  It would have been
	 better to put both the sender and recipient because if the servers
	 are ever linked they will have to make a new message type for this
	 situation.  -ed]

210 ???

	 <nick>

	 this message is sent by the server when the client attempts to browse
	 a nonexistent client.  [why don't they just use 404 for this? -ed]

211 browse a user's files

	 <nick>

	 the client sends this message when it wants to get a list of the files
	 shared by a specific client

212 browse response

	 <nick> <filename> <md5> <size> <bitrate> <frequency> <time>

	 <nick> is the user contributing the file
	 <filename> is the mp3 file contributed
	 <md5> is the has of the mp3 file
	 <size> is the file size in bytes
	 <bitrate> is the mp3 bitrate in kbps
	 <frequence> is the sampling frequency in Hz
	 <time> is the play time in seconds

	 Example:

	 foouser "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7
443332 128 44100 60

213 end of browse list

	 <nick>

	 indicates no more entries in the browse list for <user>

214 server stats

	 <users> <# files> <size>

	 <size> is approximate total library size in gigabytes
	 this message is sent by the server occasionaly without request

	 Example:

	 553 64692 254

400 join channel

	 <channel-name>

	 the client sends this command to join a channel

401 part channel

	 <channel-name>

	 the client sends this command to part a channel

402 send public message

	 <channel> <message>

403 public message

	 <channel> <nick> <text>

	 this message is sent by the server when a client sends a public message
	 to a channel.

	 Example:

	 80's espinozaf hello...hola

404 user/channel does not exist

	 <error-message>

	 This message is sent to the client when the client has requested an
	 operation on another client or channel which is invalid.

	 Examples:

	 User nosuchuser is not currently online.
	 Channel #nosuchchannel does not exist!

405 join acknowledge

	 <channel>

	 the server sends this message to the client to acknowlege that it
	 has joined the requested channel (400)

406 join message

	 <channel> <user> <sharing> <link-type>

	 <user> has joined <channel>

	 Example:

	 80's WilmaFlinstone 12 2

407 user parted channel

	 <channel> <nick> <sharing> <linespeed>

	 Example:

	 80's DLongley 23 7

408 channel user list entry

	 this message is identical to the join (406) message.  the server will
	 send the list of users in the channel prior to the client join command
	 in this message.  joins that occur after the client has joined will
	 be noted by a 406 message.

409 end of channel user list

	 <channel>

	 this message is sent by the server to indicate it has sent all informati about
the users in a channel

410 channel topic

	 <channel> <topic>

	 sent when joining a channel or a new topic is set.  a client requesting
	 topic change also uses this message.

	 [why didn't they put a field to indicate WHO changed the topic?  as
	 it is now you can only tell that it was changed.  -ed]

600 ??? upload/download ack

	 <nick>

	 <nick> is the user we are uploading/downloading to/from

	 client request.

	 [it appears that a requesting client notifies the server that it
	 has accepted the transaction with <nick>.  -ed]

601 ??? end of download ack

	 <nick> <linespeed>

	 <nick> is the user we are requesting a file from

	 server response.

	 [it appears to be the response to a 600 client message notifying that
	 the transaction has completed.  -ed]

603 whois request

	 <nick>

604 whois response

	 <nick> <user-level> <time> <channels> <status> <shared> <downloads> <uploads>
<link-type> <client-info>

	 <user-level> is one of "User" or "Admin"
	 <time> is seconds this user has been connected
	 <channels> is the list of channels the client is a member of
	 <status> is one of "Active." or "Inactive." if they are on or offline
	 <shared> is number of files user has available for download
	 <downloads> is the current number of downloads in progress
	 <uploads> is the current number of uploads in progress(?, or complete)
	 <link-type> see 0x02 (client login) above
	 <client-info> see 0x02 (client login) above

	 Example:

	 lefty "User" 1203 "80's " "Active." 0 0 0 3 "nap v0.8"

606 change user level

	 <nick> <level>

	 changes the privileges for <nick> to <level>.  client must be admin
	 level to execute this request

	 [I have not verified this message since I don't have admin status
	 on any of the servers.  -ed]

607 upload request

	 <nick> <filename>

	 this message is used to notify the client that user <nick> has
	 requested upload of <filename>

	 Example:

	 lefty "generic band - generic song.mp3"

608 upload finished

	 <nick> <filename>

	 client is notifying server that upload of <filename> to <nick> is
	 complete

	 Example:

	 lefty "generic band - generic song.mp3"

610 kill (disconnect) a user

	 <nick>

	 client request to disconnect a user.  client must be "Admin" level to
	 execute this command

611 nuke a user

	 <nick>

	 client request to delete account for <nick>

621 message of the day.  sent after client login

	 <motd-text>

	 each 621 message contains a single line of text

622 muzzle a user

	 <nick> <time>

	 client requests that <nick> not be allowed to send public messages
	 for <time> seconds

	 [the exact format of this message is unknown.  nap v0.8 just passes
	 whatever you type with /muzzle to the server.  -ed]

623 unmuzzle a user

	 <nick>

	 client requests that the enforced silence on <nick> be lifted

626 ???

	 <nick>

	 client to server message

627 operator message

	 <text>

	 client request to send a message to all admins/moderators

628 global message

	 <text>

	 client request send a message to all users

3.  MD5

The MD5 sum on the files for the upload list is computed against exactly
300000 bytes at the beginning of the file.  I have verified this :)
Hope this helps :).
The cmdline client (nap v0.7) does do some validation that the file is
consistant with what an MP3 should look like, so it looks like it's
checking the mp3 header for the file (skipping over any ID3 tag at the
beginning of the file).  You might or might not want to do similar
checking in your client.  (I can probably provide you with code for this
since I've dealt with mp3 decoding before).   I know this last bit because
it refused to compute the md5 sum on any test file I created that wasn't
made by pulling the first X bytes out of a valid MP3 (ie, sequential
bytes, or random bytes or anything but valid mp3)

[This section was contributed by JT <jtraub@...>.  -ed]

4.  Where to get more help?

Join the napdev mailing list by sending email to napdev-subscribe@onelist.com
or by visiting the community page http://www.onelist.com/community/napdev/.
This list is designed for open source napster developers to share information
about the specification or applications.

>Not quite true.  If some idiot changes their email address after
>registering, this will tell them that, but it's pretty damned useless.
>I'd implement it just to make the protocol exactly, since there are
>clients that will send you that info.

I wasn't planning on not supporting it, I was just pondering what should be
done with it isn't given.  After thinking about it for a bit I decided the
best way to deal with it is to allow the registration
even if the email is not given, and just send a bogus email address.
The current napster servers don't seem to mind, so in order to be
compatible I will not drop the connection if the wrong message is sent.

On Tue, 7 Dec 1999, Dr. Scholl wrote:

> It doesn't seem to serve any purpose from what I can tell.  The server
> will only send you that message if you have the correct password, so a
> simple ACK from the server would suffice.  The only thing that it
> really tells you is if your nick is really registered or not.  If it
> differs from what your client thinks it is, then you have not
> registered on that server.

Not quite true.  If some idiot changes their email address after
registering, this will tell them that, but it's pretty damned useless.
I'd implement it just to make the protocol exactly, since there are
clients that will send you that info.

--JT

--
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]

>A question I have been having, is what exactly is the email used for? As
>far as
>I have seen it is some sort of authorization thing, where the client would
>check
>the email address sent from the server with the one on file. Has anyone
>come up
>with an alternative reason?

It doesn't seem to serve any purpose from what I can tell.  The server
will only send you that message if you have the correct password, so
a simple ACK from the server would suffice.  The only thing that it
really tells you is if your nick is really registered or not.  If it
differs from what your client thinks it is, then you have not registered on
that server.

"Dr. Scholl" wrote:
>
> From: "Dr. Scholl" <drscholl@...>
>
> I've looked over several of the open source napster clients and it looks
> like there is some confusion as to how you go about registering a nickname.
> napster does allow you to log in anonymously so long as
> the nick you are using is not registered, but to do a registration you first
> send the client registration request (7), and then send the "alternative"
> (for lack of a better term) login message (6) which looks like a normal
> login message (3) except that you put the email address after the linespeed
> field.  I'm not sure what the actual servers do if you send a normal login
> message after sending a registration request.  Currently my implementation
> will NOT register the nick, but perhaps I should change it to do the
> registration but put a fake email address in.

A question I have been having, is what exactly is the email used for? As far as
I have seen it is some sort of authorization thing, where the client would check
the email address sent from the server with the one on file. Has anyone come up
with an alternative reason?

--
Ryan Dahl

I've looked over several of the open source napster clients and it looks
like there is some confusion as to how you go about registering a nickname.
napster does allow you to log in anonymously so long as
the nick you are using is not registered, but to do a registration you first
send the client registration request (7), and then send the "alternative"
(for lack of a better term) login message (6) which looks like a normal
login message (3) except that you put the email address after the linespeed
field.  I'm not sure what the actual servers do if you send a normal login
message after sending a registration request.  Currently my implementation
will NOT register the nick, but perhaps I should change it to do the
registration but put a fake email address in.

I found quite a number of errors in the messages for requesting files.
Also added are some of the admin commands, though I don't know what
the server responses to those are.
napster messages
================

by drscholl@...
December 6, 1999

0.  Forward

This is meant to be an open specification.  If you find errors or know of
additional functionality not described hereafter, please send me email.  It
benefits the entire community to have a complete and accurate protocol
specification.  Not only does it allow for clients to be developed for any
platform, but also decreases the strain on the server having to parse out
bad client messages.

Disclaimer: the following information was gathered by analyzing the protocol
between the linux nap client and may not resemble the official windows client
protocol.

1.  Client-Server protocol

each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 byte each.  <length> specifies the length in
bytes of the <data> portion of the message.  Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first).

Note that in many cases, strings are passed as double-quoted entries.  For
example, filenames and client id strings are always sent as
	 "nap v0.8"
or
	 "random band - generic cowboy song.mp3"

Note that unlike the IRC protocol, each line does NOT end in \r\n.  The
<length> field specifies exactly how much data you should read.

2.  Message Types

<type> can be one of the following (converted to big-endian):

0 error message

	 <message>

2 client login message

	 <username> <password> <port> <client-info> <link-type>

	 <port> is the port the client is listening on for data transfer
	 <client-info> is a string containing the client version info
	 <link-type> is an integer indicating the client's bandwidth
		 0  unknown
		 1  14.4 kbps
		 2  28.8 kpbs
		 3  33.6 kbps
		 4  56.7 kbps
		 5  64K ISDN
		 6  128K ISDN
		 7  Cable
		 8  DSL
		 9  T1
		 10 T3 or greater

	 Example:

	 foo badpass 6699 "nap v0.8" 3

3 email address server response (sent in response to 0x02)

	 <email>

6 alternate login format

	 this message is used when logging in for the first time after
	 registering (0x07) a nick

	 <nick> <pass> <port> <client-info> <linkspeed> <email-address>

	 note: this message is similar to the 0x02 message, with the addition
	 of <email-address> on the end

	 Example:

	 foo foo 6699 "nap v0.8" 3 email@...

7 client registration message

	 <nick>

	 this message is sent to create an account

	 response to this message is one of 0x08, 0x09, 0x0a

8 registration success

	 the server sends this when the clients request to register a new
	 nickname has succeeded

9 nickname already registered

	 the server sends this message when the nickname the client has
	 requested has already been registered by another user

10 invalid nickname

	 this server sends this message when the client attempts register
	 an invalid nickname [what defines an invalid nickname? -ed]

0x64 client notification of shared file

	 <filename> <md5> <size> <bitrate> <frequency> <time>

	 <md5> see section "MD5"
	 <size> is bytes
	 <bitrate> is kbps
	 <frequency> is hz
	 <time> is seconds

	 Example:

	 "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128
44100 60

200 client search request

     [FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
"song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
<compare> "<freq>"]

         The artist name and the song name are, obviously, treated
                 the same by the server; confirm this for yourself
                 on the windows client.

         max is a number; if it is greater than 100, the server will
                 only return 100 results.

         <compare> is one of the following:
                 "AT LEAST" "AT BEST" "EQUAL TO"

         <link-type> see 0x02 (client login) for a description

         <br> is a number, in kbps

         <freq> is a sample frequency, in Hz

         The windows client filters by ping time inside the client.
                 It pretty much has to, and it's easy to see the
                 result by setting ping time to at best 100 ms or
                 so, and max search terms to 50.  You'll get back
                 like 3 results, but the client will still tell you
                 that it found "50 results".

         Examples:
                 FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
                          CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"

                 MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
                         "EQUAL TO" 10

	 [Thanks to Ben Byer <bbyer@...> for this contribution.  -ed]

201 server response to search

	 <filename> <md5> <size> <bitrate> <frequency> <files-shared> <nick> <ip>
<link-type>

	 <md5> see secton "MD5"
	 <size> is file size in bytes
	 <bitrate> is mp3 bit rate in kbps
	 <frequency> is sample rate in hz
	 <files-shared> is the number of files this person is sharing
	 <nick> the person sharing the file
	 <ip> is an unsigned long integer representing the ip address of the
		 user with this file
	 <link-type> see message client login (2) message for a description

	 Example:

	 "random band - random song.mp3" 7d733c1e7419674744768db71bff8bcd 2558199 128
44100 159 lefty 3437166285 4

202 end of search response from server (0 byte data section)

203 download request

	 <nick> <filename>

	 client requests to download <filename> from <nick>

	 Example:

	 mred "C:\Program Files\Napster\generic cowboy song.mp3"

204 download ack

	 <nick> <ip> <port> <filename> <md5> <linespeed>

	 server sends this message in response to a 203 request.

	 <nick> is the user who has the file
	 <ip> is an unsigned long integer representing the ip address
	 <port> is the port <nick> is listening on
	 <filename> is the file to retrieve
	 <md5> is the md5 sum
	 <linespeed> is the user's connection speed (see login(2))

	 Example:

	 lefty 4877911892 6699 "Red_Elvises-Closet_Disco_Dancer.mp3"
10fe9e623b1962da85eea61df7ac1f69 3

205 private message to/from another user

	 <nick> <message>

	 note the same type is used for a client sending a msg or recieving one

	 [Commentary: this message causes problems if you consider linking
	 servers together.  With the current one server situation, the server
	 just rewrites the message it receives with the name of the client that
	 sent it and passes it to the recipient client.  However, in the case
	 where the recipient and sender are not on the same server, there is
	 loss of information without encapsulating it.  It would have been
	 better to put both the sender and recipient because if the servers
	 are ever linked they will have to make a new message type for this
	 situation.  -ed]

210 ???

	 <nick>

	 this message is sent by the server when the client attempts to browse
	 a nonexistent client.  [why don't they just use 404 for this? -ed]

211 browse a user's files

	 <nick>

	 the client sends this message when it wants to get a list of the files
	 shared by a specific client

212 browse response

	 <nick> <filename> <md5sum> <size> <bitrate> <frequency> <time>

	 Example:

	 foouser "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7
443332 128 44100 60

213 end of browse list

	 <nick>

	 indicates no more entries in the browse list for <user>

214 server stats

	 <users> <# files> <size>

	 <size> is approximate total library size in gigabytes
	 this message is sent by the server occasionaly without request

	 Example:

	 553 64692 254

400 join channel

	 <channel-name>

	 the client sends this command to join a channel

401 part channel

	 <channel-name>

	 the client sends this command to part a channel

402 send public message

	 <channel> <message>

403 public message

	 <channel> <nick> <text>

	 this message is sent by the server when a client sends a public message
	 to a channel.

	 Example:

	 80's espinozaf hello...hola

404 user/channel does not exist

	 <error-message>

	 This message is sent to the client when the client has requested an
	 operation on another client or channel which is invalid.

	 Examples:

	 User nosuchuser is not currently online.
	 Channel #nosuchchannel does not exist!

405 join acknowledge

	 <channel>

	 the server sends this message to the client to acknowlege that it
	 has joined the requested channel (400)

406 join message

	 <channel> <user> <sharing> <link-type>

	 <user> has joined <channel>

	 Example:

	 80's WilmaFlinstone 12 2

407 user parted channel

	 <channel> <nick> <sharing> <linespeed>

	 Example:

	 80's DLongley 23 7

408 channel user list entry

	 this message is identical to the join (406) message.  the server will
	 send the list of users in the channel prior to the client join command
	 in this message.  joins that occur after the client has joined will
	 be noted by a 406 message.

409 end of channel user list

	 <channel>

	 this message is sent by the server to indicate it has sent all informati about
the users in a channel

410 channel topic

	 <channel> <topic>

	 sent when joining a channel or a new topic is set

600 ??? upload/download ack

	 <nick>

	 <nick> is the user we are uploading/downloading to/from

	 client request.

	 [it appears that a requesting client notifies the server that it
	 has accepted the transaction with <nick>.  -ed]

601 ??? end of download ack

	 <nick> <linespeed>

	 <nick> is the user we are requesting a file from

	 server response.

	 [it appears to be the response to a 600 client message notifying that
	 the transaction has completed.  -ed]

603 whois request

	 <nick>

604 whois response

	 <nick> <user-level> <time> <channels> <status> <shared> <downloads> <uploads>
<link-type> <client-info>

	 <user-level> is one of "User" or "Admin"
	 <time> is seconds this user has been connected
	 <channels> is the list of channels the client is a member of
	 <status> is one of "Active.", ???
	 <shared> is number of files user has available for download
	 <downloads> is the current number of downloads in progress
	 <uploads> is the current number of uploads in progress(?, or complete)
	 <link-type> see 0x02 (client login) above
	 <client-info> see 0x02 (client login) above

	 Example:

	 lefty "User" 1203 "80's " "Active." 0 0 0 3 "nap v0.8"

606 change user level

	 <nick> <level>

	 changes the privileges for <nick> to <level>.  client must be admin
	 level to execute this request

	 [I have not verified this message since I don't have admin status
	 on any of the servers.  -ed]

607 upload request

	 <nick> <filename>

	 this message is used to notify the client that user <nick> has
	 requested upload of <filename>

	 Example:

	 lefty "Red_Elvises-Closet_Disco_Dancer.mp3"

608 upload finished

	 <nick> <filename>

	 client is notifying server that upload of <filename> to <nick> is
	 complete

	 Example:

	 lefty "Red_Elvises-Closet_Disco_Dancer.mp3"

610 kill (disconnect) a user

	 <nick>

	 client request to disconnect a user.  client must be "Admin" level to
	 execute this command

611 nuke a user

	 <nick>

	 client request to delete account for <nick>

621 message of the day.  sent after client login

	 <motd-text>

	 each 621 message contains a single line of text

626 ???

	 <nick>

	 client to server message

627 operator message

	 <text>

	 client request to send a message to all admins/moderators

628 global message

	 <text>

	 client request send a message to all users

3.  MD5

The MD5 sum on the files for the upload list is computed against exactly
300000 bytes at the beginning of the file.  I have verified this :)
Hope this helps :).
The cmdline client (nap v0.7) does do some validation that the file is
consistant with what an MP3 should look like, so it looks like it's
checking the mp3 header for the file (skipping over any ID3 tag at the
beginning of the file).  You might or might not want to do similar
checking in your client.  (I can probably provide you with code for this
since I've dealt with mp3 decoding before).   I know this last bit because
it refused to compute the md5 sum on any test file I created that wasn't
made by pulling the first X bytes out of a valid MP3 (ie, sequential
bytes, or random bytes or anything but valid mp3)

[This section was contributed by JT <jtraub@...>.  -ed]

A friend of mine forwarded me Eliot Landrum's post "Jabster Proposal" about
Napster to this list.

I'm the author of gnome-napster, so I thought I should reply to a few points
in his email.

- The Napster Protocol:
Yes, it is ugly.  Yes, the messaging protocol seems redundant, which is why
it is at the bottom of my TODO list.
Discussion of the Napster protocol is current on the "napdev" mailing list,
at http://www.onelist.com/community/napdev .  This is where the protocol is
discussed.

- Napster Server:
"drscholl" (drscholl@...) is currently developing a open source
Napster server, and documenting the protocol as he does it.  I try to keep
the latest version of his protocol specification on my home page
(http://students.washington.edu/eeyem/), which is also where anybody
interested can download my Napster client.  To just look at the protocol
spec, visit http://students.washington.edu/eeyem/gn/napster.txt .
Napster uses multiple unlinked servers.  This means that the content on each
server is independent of the others.  Napster servers are probably under
incredible loads, because searching is expensive.
The Napster protocol currently has a few design flaws that prevent linking
the servers.  This could be worked around, but it would break compatibility
with the existing protocol.  The Windows client doesn't let you specify a
server anyway, so that may be a nonissue.

- Server Design:
Eliot wrote, "- Server gathers list of results, checks to see which of the
hosts that have
the requested songs are online, pings them and sends list back to client."
This would add the additional load of pinging to the server, which isn't a
good idea and doesn't accurately represent the client-client ping anyway.
I appreciate that the idea is new, I just thought I should add that you
should offload as much processing as possible to the client.

Finally, is there a mailing list archive where I could read the responses to
his post?

Evan.

(To the napdev list members: jabber is a messaging client, visit
http://www.jabber.org for more information.)

The answer is, no, it doesn't do escaping of quotes.  If you try searching
for the phrase 'a "quoted" string' on the windows client, you get no songs
found, and "invalid search request" printed in yellow in your console
window.  (don't know what code that is, sorry.)

and no wonder-- a little birdie told me that the client sends this:

FILENAME CONTAINS "a "quoted" string" MAX_RESULTS 100

Ben

> > So I'm not sure what happens if you have a filename with quotes in it.
>
>If a filename does have quotes in it, it is escaped correctly.

Could you give some more detailed information?  How exactly is it
escaped?  If with a backkslash, how do you tell a normal unescaped
string from an escaped one?  Please supply and example for the spec.
Thanks.

On Mon, Dec 06, 1999 at 03:30:32PM -0800, Dr. Scholl wrote:
> I have not seen any quoted messages.  I do know that backslash (\) is
> not quoted, because you get filenames like:
>  "C:\Program Files\Napster\foo.mp3"
> So I'm not sure what happens if you have a filename with quotes in it.

If a filename does have quotes in it, it is escaped correctly.

--
Ryan Dahl

I have not seen any quoted messages.  I do know that backslash (\) is
not quoted, because you get filenames like:
	 "C:\Program Files\Napster\foo.mp3"
So I'm not sure what happens if you have a filename with quotes in it.

>I notice any strings with spaces (or the possibility of having spaces) seem
>to
>be enclosed in quotes .. could you confirm that if the strings contain
>quotes
>themselves they are escaped?
>
>e.g.
>
>"my name is \"Iain\""    OR
>"\"C:\\Program Files\\Banana\\\"
>
>or something..

>taking ben's lead, i've added some more examples to some of the message
>types.  i've also switched to using integers for the message  types instead
>of hex.

I notice any strings with spaces (or the possibility of having spaces) seem
to
be enclosed in quotes .. could you confirm that if the strings contain
quotes
themselves they are escaped?

e.g.

"my name is \"Iain\""    OR
"\"C:\\Program Files\\Banana\\\"

or something..

Thx,
-Iain

taking ben's lead, i've added some more examples to some of the message
types.  i've also switched to using integers for the message  types instead
of hex.
napster messages
================

by drscholl@...
December 6, 1999

0.  Forward

This is meant to be an open specification.  If you find errors or know of
additional functionality not described hereafter, please send me email.  It
benefits the entire community to have a complete and accurate protocol
specification.  Not only does it allow for clients to be developed for any
platform, but also decreases the strain on the server having to parse out
bad client messages.

Disclaimer: the following information was gathered by analyzing the protocol
between the linux nap client and may not resemble the official windows client
protocol.

1.  Client-Server protocol

each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 byte each.  <length> specifies the length in
bytes of the <data> portion of the message.  Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first).

Note that in many cases, strings are passed as double-quoted entries.  For
example, filenames and client id strings are always sent as
	 "nap v0.8"
or
	 "random band - generic cowboy song.mp3"

Note that unlike the IRC protocol, each line does NOT end in \r\n.  The
<length> field specifies exactly how much data you should read.

2.  Message Types

<type> can be one of the following (converted to big-endian):

0 error message

	 <message>

2 client login message

	 <username> <password> <port> <client-info> <link-type>

	 <port> is the port the client is listening on for data transfer
	 <client-info> is a string containing the client version info
	 <link-type> is an integer indicating the client's bandwidth
		 0  unknown
		 1  14.4 kbps
		 2  28.8 kpbs
		 3  33.6 kbps
		 4  56.7 kbps
		 5  64K ISDN
		 6  128K ISDN
		 7  Cable
		 8  DSL
		 9  T1
		 10 T3 or greater

	 Example:

	 foo badpass 6699 "nap v0.8" 3

3 email address server response (sent in response to 0x02)

	 <email>

6 alternate login format

	 this message is used when logging in for the first time after
	 registering (0x07) a nick

	 <nick> <pass> <port> <client-info> <linkspeed> <email-address>

	 note: this message is similar to the 0x02 message, with the addition
	 of <email-address> on the end

	 Example:

	 foo foo 6699 "nap v0.8" 3 email@...

7 client registration message

	 <nick>

	 this message is sent to create an account

	 response to this message is one of 0x08, 0x09, 0x0a

8 registration success

	 the server sends this when the clients request to register a new
	 nickname has succeeded

9 nickname already registered

	 the server sends this message when the nickname the client has
	 requested has already been registered by another user

10 invalid nickname

	 this server sends this message when the client attempts register
	 an invalid nickname [what defines an invalid nickname? -ed]

0x64 client notification of shared file

	 <filename> <md5> <size> <bitrate> <frequency> <time>

	 <md5> see section "MD5"
	 <size> is bytes
	 <bitrate> is kbps
	 <frequency> is hz
	 <time> is seconds

	 Example:

	 "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7 443332 128
44100 60

200 client search request

     [FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
"song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
<compare> "<freq>"]

         The artist name and the song name are, obviously, treated
                 the same by the server; confirm this for yourself
                 on the windows client.

         max is a number; if it is greater than 100, the server will
                 only return 100 results.

         <compare> is one of the following:
                 "AT LEAST" "AT BEST" "EQUAL TO"

         <link-type> see 0x02 (client login) for a description

         <br> is a number, in kbps

         <freq> is a sample frequency, in Hz

         The windows client filters by ping time inside the client.
                 It pretty much has to, and it's easy to see the
                 result by setting ping time to at best 100 ms or
                 so, and max search terms to 50.  You'll get back
                 like 3 results, but the client will still tell you
                 that it found "50 results".

         Examples:
                 FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
                          CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"

                 MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
                         "EQUAL TO" 10

	 [Thanks to Ben Byer <bbyer@...> for this contribution.  -ed]

201 server response to search

	 <filename> <md5> <size> <bitrate> <frequency> <files-shared> <nick>
<collection-size> <link-type>

	 <md5> see secton "MD5"
	 <size> is file size in bytes
	 <bitrate> is mp3 bit rate in kbps
	 <frequency> is sample rate in hz
	 <files-shared> is the number of files this person is sharing
	 <nick> the person sharing the file
	 <collection-size> size in bytes of this user's collection
	 <link-type> see message client login (2) message for a description

	 Example:

	 "random band - random song.mp3" 7d733c1e7419674744768db71bff8bcd 2558199 128
44100 159 lefty 3437166285 4

202 end of search response from server (0 byte data section)

205 private message to/from another user

	 <nick> <message>

	 note the same type is used for a client sending a msg or recieving one

	 [Commentary: this message causes problems if you consider linking
	 servers together.  With the current one server situation, the server
	 just rewrites the message it receives with the name of the client that
	 sent it and passes it to the recipient client.  However, in the case
	 where the recipient and sender are not on the same server, there is
	 loss of information without encapsulating it.  It would have been
	 better to put both the sender and recipient because if the servers
	 are ever linked they will have to make a new message type for this
	 situation.  -ed]

210 ???

	 <nick>

	 this message is sent by the server when the client attempts to browse
	 a nonexistent client.  [why don't they just use 404 for this? -ed]

211 browse a user's files

	 <nick>

	 the client sends this message when it wants to get a list of the files
	 shared by a specific client

212 browse response

	 <nick> <filename> <md5sum> <size> <bitrate> <frequency> <time>

	 Example:

	 foouser "generic band - generic song.mp3" b92870e0d41bc8e698cf2f0a1ddfeac7
443332 128 44100 60

213 end of browse list

	 <nick>

	 indicates no more entries in the browse list for <user>

214 server stats (<users> <# files> <size>)

	 <size> is approximate total library size in gigabytes
	 this message is sent by the server occasionaly without request

400 join channel

	 <channel-name>

	 the client sends this command to join a channel

401 part channel

	 <channel-name>

	 the client sends this command to part a channel

402 send public message

	 <channel> <message>

403 public message

	 <channel> <nick> <text>

	 this message is sent by the server when a client sends a public message
	 to a channel.

	 Example:

	 80's espinozaf hello...hola

404 user/channel does not exist

	 <error-message>

	 This message is sent to the client when the client has requested an
	 operation on another client or channel which is invalid.

	 Examples:

	 User nosuchuser is not currently online.
	 Channel #nosuchchannel does not exist!

406 join message

	 <channel> <user> <sharing> <link-type>

	 <user> has joined <channel>

	 Example:

	 80's WilmaFlinstone 12 2

407 user parted channel

	 <channel> <nick> <sharing> <linespeed>

	 Example:

	 80's DLongley 23 7

408 channel user list entry

	 this message is identical to the join (406) message.  the server will
	 send the list of users in the channel prior to the client join command
	 in this message.  joins that occur after the client has joined will
	 be noted by a 406 message.

409 end of channel user list

	 <channel>

	 this message is sent by the server to indicate it has sent all informati about
the users in a channel

410 channel topic

	 <channel> <topic>

	 sent when joining a channel or a new topic is set

603 whois request

	 <nick>

604 whois response

	 <nick> <user-level> <time> <channels> <status> <uploads> <downloads> <sharing>
<link-type> <client-info>

	 <user-level> is one of "User" or "Admin"
	 <time> is seconds this user has been connected
	 <channels> is the list of channels the client is a member of
	 <status> is one of "Active.", ???
	 <uploads> is the current number of uploads in progress(?, or complete)
	 <downloads> is the current number of downloads in progress
	 <sharing> is number of files user has available for download
	 <link-type> see 0x02 (client login) above
	 <client-info> see 0x02 (client login) above

	 Example:

	 kuila0 "User" 1203 "80's " "Active." 0 0 0 3 "nap v0.8"

621 message of the day.  sent after client login

	 <motd-text>

	 each 621 message contains a single line of text

3.  MD5

The MD5 sum on the files for the upload list is computed against exactly
300000 bytes at the beginning of the file.  I have verified this :)
Hope this helps :).
The cmdline client (nap v0.7) does do some validation that the file is
consistant with what an MP3 should look like, so it looks like it's
checking the mp3 header for the file (skipping over any ID3 tag at the
beginning of the file).  You might or might not want to do similar
checking in your client.  (I can probably provide you with code for this
since I've dealt with mp3 decoding before).   I know this last bit because
it refused to compute the md5 sum on any test file I created that wasn't
made by pulling the first X bytes out of a valid MP3 (ie, sequential
bytes, or random bytes or anything but valid mp3)

[This section was contributed by JT <jtraub@...>.  -ed]

>when you send the login (2) request add the email address on to the end of
>the line (but only if you are registering a nick, not after you have
>already
>created an account).

i goofed here.  nap sends message 6 which looks like 2 except that it has
the email address tacked on the end:

	 foo foo 6699 "nap v0.8" 3 email@...

ok, i figured out how the client registration part works by looking at what
nap does.  basically you send a request (7) with the nick to use, and the
server returns one of
	 8 ok
	 9 already registered
	 10 invalid nick
when you send the login (2) request add the email address on to the end of
the line (but only if you are registering a nick, not after you have already
created an account).

attached is the updated spec.
napster messages
================

by drscholl@...
December 6, 1999

0.  Forward

This is meant to be an open specification.  If you find errors or know of
additional functionality not described hereafter, please send me email.  It
benefits the entire community to have a complete and accurate protocol
specification.  Not only does it allow for clients to be developed for any
platform, but also decreases the strain on the server having to parse out
bad client messages.

Disclaimer: the following information was gathered by analyzing the protocol
between the linux nap client and may not resemble the official windows client
protocol.

1.  Client-Server protocol

each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 byte each.  <length> specifies the length in
bytes of the <data> portion of the message.  Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first).

Note that in many cases, strings are passed as double-quoted entries.  For
example, filenames and client id strings are always sent as
	 "nap v0.8"
or
	 "random band - generic cowboy song.mp3"

Note that unlike the IRC protocol, each line does NOT end in \r\n.  The
<length> field specifies exactly how much data you should read.

2.  Message Types

<type> can be one of the following (converted to big-endian):

0x00 error message

	 <message>

0x02 client login message

	 <username> <password> <port> <client-info> <link-type> [ <email-address> ]

	 <port> is the port the client is listening on for data transfer
	 <client-info> is a string containing the client version info
	 <link-type> is an integer indicating the client's bandwidth
		 0  unknown
		 1  14.4 kbps
		 2  28.8 kpbs
		 3  33.6 kbps
		 4  56.7 kbps
		 5  64K ISDN
		 6  128K ISDN
		 7  Cable
		 8  DSL
		 9  T1
		 10 T3 or greater
	 <email-address> is the user's email address.  this field is only
		 present when this message follows a client registration
		 message (0x07)

0x03 email address server response (sent in response to 0x02)

	 <email>

0x07 client registration message

	 <nick>

	 this message is sent to create an account

	 response to this message is one of 0x08, 0x09, 0x0a

0x08 registration success

	 the server sends this when the clients request to register a new
	 nickname has succeeded

0x09 nickname already registered

	 the server sends this message when the nickname the client has
	 requested has already been registered by another user

0x0a invalid nickname

	 this server sends this message when the client attempts register
	 an invalid nickname [what defines an invalid nickname? -ed]

0x64 client notification of shared file

	 <filename> <md5> <size> <bitrate> <frequency> <time>

	 <md5> see section MD5
	 <size> is bytes
	 <bitrate> is kbps
	 <frequency> is hz
	 <time> is seconds

0xc8 client search request

     [FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
"song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
<compare> "<freq>"]

         The artist name and the song name are, obviously, treated
                 the same by the server; confirm this for yourself
                 on the windows client.

         max is a number; if it is greater than 100, the server will
                 only return 100 results.

         <compare> is one of the following:
                 "AT LEAST" "AT BEST" "EQUAL TO"

         <link-type> see 0x02 (client login) for a description

         <br> is a number, in kbps

         <freq> is a sample frequency, in Hz

         The windows client filters by ping time inside the client.
                 It pretty much has to, and it's easy to see the
                 result by setting ping time to at best 100 ms or
                 so, and max search terms to 50.  You'll get back
                 like 3 results, but the client will still tell you
                 that it found "50 results".

         Examples:
                 FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
                          CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"

                 MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
                         "EQUAL TO" 10

	 [Thanks to Ben Byer <bbyer@...> for this contribution.  -ed]

0xc9 server response to search

	 <filename> <md5> <size> <bitrate> <frequency> <files-shared> <nick>
<collection-size> <link-type>

	 <md5> see secton "MD5"
	 <size> is file size in bytes
	 <bitrate> is mp3 bit rate in kbps
	 <frequency> is sample rate in hz
	 <files-shared> is the number of files this person is sharing
	 <nick> the person sharing the file
	 <collection-size> size in bytes of this user's collection
	 <link-type> see 0x02 (client login) for a description

0xca end of search response from server (0 byte data section)

0xcd private message to/from another user

	 <nick> <message>

	 note the same type is used for a client sending a msg or recieving one

	 [Commentary: this message causes problems if you consider linking
	 servers together.  With the current one server situation, the server
	 just rewrites the message it receives with the name of the client that
	 sent it and passes it to the recipient client.  However, in the case
	 where the recipient and sender are not on the same server, there is
	 loss of information without encapsulating it.  It would have been
	 better to put both the sender and recipient because if the servers
	 are ever linked they will have to make a new message type for this
	 situation.  -ed]

0x00d3 browse a user's files

	 <nick>

0x00d4 browse response

	 <nick> <filename> <md5sum> <size> <bitrate> <frequency> <time>

0x00d5 end of browse list

	 <nick>

	 indicates no more entries in the browse list for <user>

0xd6 server stats (<users> <# files> <size>)

	 <size> is approximate total library size in gigabytes
	 this message is sent by the server occasionaly without request

0x025b whois request

	 <nick>

0x025c whois response

	 <nick> <user-level> <time> <status> <uploads> <downloads> <sharing> <link-type>
<client-info>

	 <user-level> is one of "User" or "Admin"
	 <time> is seconds this user has been connected
	 <status> is one of "Active.", ???
	 <uploads> is the current number of uploads in progress(?, or complete)
	 <downloads> is the current number of downloads in progress
	 <sharing> is number of files user has available for download
	 <link-type> see 0x02 (client login) above
	 <client-info> see 0x02 (client login) above

0x0190 join channel

	 <channel-name>

0x0191 part channel

	 <channel-name>

0x0192 send public message

	 <channel> <message>

0x0193 receive public message

	 <channel> <user> <message>

0x0195 ???

	 <channel>

0x0196 join message

	 <channel> <user> <sharing> <link-type>

	 <user> has joined <channel>

0x0198 channel user list

	 <channel> <user> <sharing> <link-type>

0x0199 end of channel list

	 <channel>

0x019a channel topic

	 <channel> <topic>

	 sent when joining a channel or a new topic is set

404 channel does not exist

0x6d02 message of the day.  sent after client login

3.  MD5

The MD5 sum on the files for the upload list is computed against exactly
300000 bytes at the beginning of the file.  I have verified this :)
Hope this helps :).
The cmdline client (nap v0.7) does do some validation that the file is
consistant with what an MP3 should look like, so it looks like it's
checking the mp3 header for the file (skipping over any ID3 tag at the
beginning of the file).  You might or might not want to do similar
checking in your client.  (I can probably provide you with code for this
since I've dealt with mp3 decoding before).   I know this last bit because
it refused to compute the md5 sum on any test file I created that wasn't
made by pulling the first X bytes out of a valid MP3 (ie, sequential
bytes, or random bytes or anything but valid mp3)

[This section was contributed by JT <jtraub@...>.  -ed]

>The client registration message (in gnap at least, which is where I stole
>my code from) is 0x07, not 0x01.  I refer you to napster.c lines 53-60:
>  if(new_user) {
>  [...]
>   send(socketfd,"\7",2,0);
>
>And the format is simply
><username>
>.
>I'm not sure what the difference is. :(

Hmm, I was just thinking about this...  I thought the registration
message also had the email address in it?  If not, where does that
come from?  Guess I'll have to use nap to create a new account and look.

> 0xc8 client search request

Submitted for your consideration:

     [FILENAME CONTAINS "artist name"] MAX_RESULTS <max> [FILENAME CONTAINS
"song"] [LINESPEED <compare> <link-type>] [BITRATE <compare> "<br>"] [FREQ
<compare> "<freq>"]

	 The artist name and the song name are, obviously, treated
		 the same by the server; confirm this for yourself
		 on the windows client.

	 max is a number; if it is greater than 100, the server will
		 only return 100 results.

	 <compare> is one of the following:
		 "AT LEAST" "AT BEST" "EQUAL TO"

	 <link-type> see 0x02 (client login) for a description

	 <br> is a number, in kbps

	 <freq> is a sample frequency, in Hz

	 The windows client filters by ping time inside the client.
		 It pretty much has to, and it's easy to see the
		 result by setting ping time to at best 100 ms or
		 so, and max search terms to 50.  You'll get back
		 like 3 results, but the client will still tell you
		 that it found "50 results".

	 Examples:
		 FILENAME CONTAINS "Sneaker Pimps" MAX_RESULTS 75 FILENAME
			  CONTAINS "tesko suicide" BITRATE "AT LEAST" "128"

		 MAX_RESULTS 100 FILENAME CONTAINS "Ventolin" LINESPEED
			 "EQUAL TO" 10

Ben


Ben

On Sun, 5 Dec 1999, Ben wrote:
> It maybe a good idea to abstract the napster implementation from one
> of the gnome napster clients into a C library. Everyone could make
> sure this worked correctly and base their clients around it. If the
> protocol was suddenly changed then we would only have to change one
> implementation.
>
> Any thoughts on this? Has this been done yet?
>
> Ben.

Yes.  Look at lnap.c in gnome-napster.  It could use a bit of work, but
it's mostly independent.   The idea was to abstract it into a "libnap",
which is why it's named with an "l".

I should note that I've added some fixes since 0.3.1, so if you really
want to use this, I can give you the newer source file.
Also, much of the download logic is in another file.  I could move it
easily, I just haven't thought it was necessary.

Evan.

On Sun, Dec 05, 1999 at 04:39:43PM -0800, Evan Martin wrote:
> From: Evan Martin <eeyem@...>
>
> On Sun, 5 Dec 1999, Dr. Scholl wrote:
> > here's the latest napster protocol doc for your enjoyment.  feel free to
> > start passing this around to interested people.
>
> This looks really good.  I've put it up on my web site.

It maybe a good idea to abstract the napster implementation from one
of the gnome napster clients into a C library. Everyone could make
sure this worked correctly and base their clients around it. If the
protocol was suddenly changed then we would only have to change one
implementation.

Any thoughts on this? Has this been done yet?

Ben.

>This looks really good.  I've put it up on my web site.
>
>Points to note:
>
>v2.0 beta 4 has a clause in their licensing agreement that doesn't allow
>reverse-engineering.  I'm not sure what this means for you, but they may
>try to sue or something nasty. :\
>You could work around this by removing all references to "beta 4" in your
>document. :)

Technically I have not broken the license agreement because I have never
actually used their client.  I obtained all of this information while
running tcpdump on my linux box and using the nap client (I'm not a windows
user).  Since reverse engineering in general is not illegal, they don't have
a leg to stand on if they threaten to sue me.
I'm not even sure if they could successfully sue someone who used
their client.  Besides, the amount of bad publicity they would get if
they even tried something like that. . .

>The client registration message (in gnap at least, which is where I stole
>my code from) is 0x07, not 0x01.  I refer you to napster.c lines 53-60:
>  if(new_user) {
>  [...]
>   send(socketfd,"\7",2,0);
>
>And the format is simply
><username>
>.
>I'm not sure what the difference is. :(
>
>
>Finally, message type 0x0 is an error.  The content is the error message.
>
>Otherwise, it looks good.

Thanks, I will update the file and get a new version out.

On Sun, 5 Dec 1999, Dr. Scholl wrote:
> here's the latest napster protocol doc for your enjoyment.  feel free to
> start passing this around to interested people.

This looks really good.  I've put it up on my web site.

Points to note:

v2.0 beta 4 has a clause in their licensing agreement that doesn't allow
reverse-engineering.  I'm not sure what this means for you, but they may
try to sue or something nasty. :\
You could work around this by removing all references to "beta 4" in your
document. :)

The client registration message (in gnap at least, which is where I stole
my code from) is 0x07, not 0x01.  I refer you to napster.c lines 53-60:
  if(new_user) {
  [...]
   send(socketfd,"\7",2,0);

And the format is simply
<username>
.
I'm not sure what the difference is. :(


Finally, message type 0x0 is an error.  The content is the error message.

Otherwise, it looks good.

Evan.

here's the latest napster protocol doc for your enjoyment.  feel free to
start passing this around to interested people.
napster messages (based on napster 2.0 beta 4)
==============================================

by drscholl@...
December 5, 1999

0.  Forward

This is meant to be an open specification.  If you find errors or know of
additional functionality not described hereafter, please send me email.  It
benefits the entire community to have a complete and accurate protocol
specification.  Not only does it allow for clients to be developed for any
platform, but also decreases the strain on the server having to parse out
bad client messages.

1.  Client-Server protocol

each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 byte each.  <length> specifies the length in
bytes of the <data> portion of the message.  Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first).

Note that in many cases, strings are passed as double-quoted entries.  For
example, filenames and client id strings are always sent as
	 "v2.0 BETA 4"
or
	 "random band - generic cowboy song.mp3"

Note that unlike the IRC protocol, each line does NOT end in \r\n.  The
<length> field specifies exactly how much data you should read.

2.  Message Types

<type> can be one of the following (converted to big-endian):

0x01 client registration message

	 [format unknown (I forgot what it is)  -ed]

	 this message is sent to create an account

0x02 client login message

	 <username> <password> <port> <client-info> <link-type>

	 <port> is the port the client is listening on for data transfer
	 <client-info> is a string containing the client version info
	 <link-type> is an integer indicating the client's bandwidth
		 0  unknown
		 1  14.4 kbps
		 2  28.8 kpbs
		 3  33.6 kbps
		 4  56.7 kbps
		 5  64K ISDN
		 6  128K ISDN
		 7  Cable
		 8  DSL
		 9  T1
		 10 T3 or greater

0x03 email address server response (sent in response to 0x02)

	 <email>

0x64 client notification of shared file

	 <filename> <md5> <size> <bitrate> <frequency> <time>

	 <md5> see section MD5
	 <size> is bytes
	 <bitrate> is kbps
	 <frequency> is hz
	 <time> is seconds

0xc8 client search request

	 FILENAME CONTAINS "<string>" MAX_RESULTS 100

0xc9 server response to search

	 <filename> <md5> <size> <bitrate> <frequency> <files-shared> <nick>
<collection-size> <link-type>

	 <md5> see secton "MD5"
	 <size> is file size in bytes
	 <bitrate> is mp3 bit rate in kbps
	 <frequency> is sample rate in hz
	 <files-shared> is the number of files this person is sharing
	 <nick> the person sharing the file
	 <collection-size> size in bytes of this user's collection
	 <link-type> see 0x02 (client login) for a description

0xca end of search response from server (0 byte data section)

0xcd private message to/from another user

	 <nick> <message>

	 note the same type is used for a client sending a msg or recieving one

0x00d3 browse a user's files

	 <nick>

0x00d4 browse response

	 <nick> <filename> <md5sum> <size> <bitrate> <frequency> <time>

0x00d5 end of browse list

	 <nick>

	 indicates no more entries in the browse list for <user>

0xd6 server stats (<users> <# files> <size>)

	 <size> is approximate total library size in gigabytes
	 this message is sent by the server occasionaly without request

0x025b whois request

	 <nick>

0x025c whois response

	 <nick> <user-level> <time> <status> <uploads> <downloads> <sharing> <link-type>
<client-info>

	 <user-level> is one of "User" or "Admin"
	 <time> is seconds this user has been connected
	 <status> is one of "Active.", ???
	 <uploads> is the current number of uploads in progress(?, or complete)
	 <downloads> is the current number of downloads in progress
	 <sharing> is number of files user has available for download
	 <link-type> see 0x02 (client login) above
	 <client-info> see 0x02 (client login) above

0x0190 join channel

	 <channel-name>

0x0191 part channel

	 <channel-name>

0x0192 send public message

	 <channel> <message>

0x0193 receive public message

	 <channel> <user> <message>

0x0195 ???

	 <channel>

0x0196 join message

	 <channel> <user> <sharing> <link-type>

	 <user> has joined <channel>

0x0198 channel user list

	 <channel> <user> <sharing> <link-type>

0x0199 end of channel list

	 <channel>

0x019a channel topic

	 <channel> <topic>

	 sent when joining a channel or a new topic is set

404 channel does not exist

0x6d02 message of the day.  sent after client login

3.  MD5

[This section was contributed by JT <jtraub@...>.  -ed]

The MD5 sum on the files for the upload list is computed against exactly
300000 bytes at the beginning of the file.  I have verified this :)
Hope this helps :).
The cmdline client (nap v0.7) does do some validation that the file is
consistant with what an MP3 should look like, so it looks like it's
checking the mp3 header for the file (skipping over any ID3 tag at the
beginning of the file).  You might or might not want to do similar
checking in your client.  (I can probably provide you with code for this
since I've dealt with mp3 decoding before).   I know this last bit because
it refused to compute the md5 sum on any test file I created that wasn't
made by pulling the first X bytes out of a valid MP3 (ie, sequential
bytes, or random bytes or anything but valid mp3)

On Fri, 3 Dec 1999, Dr. Scholl wrote:
> >Evan Martin told me about the list.  He and I had been in communication
> >about his gnome napster client recently, so I wanted to make sure this
> >information was available.
>
> Thanks!  That is indeed very useful information.  I had gathered from
> lurking on #napster that they were doing something like this, but its great
> the finally have the details.  Now the linux clients can contribute their
> own libraries as well (instead of just leeching ;)
>
> Do you mind if I incorporate that information into my current documentation
> (with credit of course)?

Not at all.

--JT

--
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]

>Evan Martin told me about the list.  He and I had been in communication
>about his gnome napster client recently, so I wanted to make sure this
>information was available.

Thanks!  That is indeed very useful information.  I had gathered from
lurking on #napster that they were doing something like this, but its great
the finally have the details.  Now the linux clients can contribute their
own libraries as well (instead of just leeching ;)

Do you mind if I incorporate that information into my current documentation
(with credit of course)?

Evan Martin told me about the list.  He and I had been in communication
about his gnome napster client recently, so I wanted to make sure this
information was available.

--JT

--
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]

---------- Forwarded message ----------
Date: Thu, 2 Dec 1999 17:34:37 -0800 (PST)
From: JT <jtraub@...>
To: Evan Martin <eeyem@...>
Subject: Re: Gnome Napster

On Thu, 2 Dec 1999, Evan Martin wrote:
> Great.  Uploading support is rapidly approaching the top of the TODO list.

The MD5 sum on the files for the upload list is computed against exactly
300000 bytes at the beginning of the file.  I have verified this :)
Hope this helps :).  I'm ccing Ryan Dahl on this mail as well.
The cmdline client (nap v0.7) does do some validation that the file is
consistant with what an MP3 should look like, so it looks like it's
checking the mp3 header for the file (skipping over any ID3 tag at the
beginning of the file).  You might or might not want to do similar
checking in your client.  (I can probably provide you with code for this
since I've dealt with mp3 decoding before).   I know this last bit because
it refused to compute the md5 sum on any test file I created that wasn't
made by pulling the first X bytes out of a valid MP3 (ie, sequential
bytes, or random bytes or anything but valid mp3)

I hope this helps you both out in providing better higher quality napster
clients sooner.

--JT

--
[-------------------------------------------------------------------------]
[ Practice random kindness and senseless acts of beauty.                  ]
[ It's hard to seize the day when you must first grapple with the morning ]
[-------------------------------------------------------------------------]

> attached is what i've documented of the napster protocol so far.  note
that
> the registration message is wrong, i seem to have lost what it is.

Could you put your name, etc. on it, so I can publicly post it somewhere?

Evan.

attached is what i've documented of the napster protocol so far.  note that
the registration message is wrong, i seem to have lost what it is.
napster messages (based on napster 2.0 beta 4)
==============================================
each message to/from the server is in the form of
<length><type><data>
where <length> and <type> are 2 byte each.  <length> specifies the length in
bytes of the <data> portion of the message.  Be aware that <length> and <type>
appear to be in little-endian format (least significant byte goes first).

<type> can be one of the following (converted to big-endian):

0x01 client registration message

	 <username> <password> <email>

	 this message is sent to create an account

0x02 client login message

	 <username> <password> <port> <client-info> <link-type>

	 <port> is the port the client is listening on for data transfer
	 <client-info> is a string containing the client version info
	 <link-type> is an integer indicating the client's bandwidth
		 0  unknown
		 1  14.4 kbps
		 2  28.8 kpbs
		 3  33.6 kbps
		 4  56.7 kbps
		 5  64K ISDN
		 6  128K ISDN
		 7  Cable
		 8  DSL
		 9  T1
		 10 T3 or greater

0x03 email address server response (sent in response to 0x02)

	 <email>

0x64 client notification of shared file

	 <filename> <md5sum> <size> <bitrate> <frequency> <time>

	 <size> is bytes
	 <bitrate> is kbps
	 <frequency> is hz
	 <time> is seconds

0xc8 client search request

	 FILENAME CONTAINS "<string>" MAX_RESULTS 100

0xc9 server response to search

	 <filename> <md5sum> <size> <bitrate> <frequency> <files-shared> <nick>
<collection-size> <n>

	 <md5sum> checksum of file
	 <size> is file size in bytes
	 <bitrate> is mp3 bit rate in kbps
	 <frequency> is sample rate in hz
	 <files-shared> is the number of files this person is sharing
	 <nick> the person sharing the file
	 <collection-size> size in bytes of this user's collection
	 <link-type> see 0x02 (client login) for a description

0xca end of search response from server (0 byte data section)

0xcd private message to/from another user

	 <nick> <message>

	 note the same type is used for a client sending a msg or recieving one

0x00d3 browse a user's files

	 <nick>

0x00d4 browse response

	 <nick> <filename> <md5sum> <size> <bitrate> <frequency> <time>

0x00d5 end of browse list

	 <nick>

	 indicates no more entries in the browse list for <user>

0xd6 server stats (<users> <# files> <size>)

	 <size> is approximate total library size in gigabytes
	 this message is sent by the server occasionaly without request

0x025b whois request

	 <nick>

0x025c whois response

	 <nick> <user-level> <time> <status> <uploads> <downloads> <sharing> <link-type>
<client-info>

	 <user-level> is one of "User" or "Admin"
	 <time> is seconds this user has been connected
	 <status> is one of "Active.", ???
	 <uploads> is the current number of uploads in progress(?, or complete)
	 <downloads> is the current number of downloads in progress
	 <sharing> is number of files user has available for download
	 <link-type> see 0x02 (client login) above
	 <client-info> see 0x02 (client login) above

0x0190 join channel

	 <channel-name>

0x0191 part channel

	 <channel-name>

0x0192 send public message

	 <channel> <message>

0x0193 receive public message

	 <channel> <user> <message>

0x0195 ???

	 <channel>

0x0196 join message

	 <channel> <user> <sharing> <link-type>

	 <user> has joined <channel>

0x0198 channel user list

	 <channel> <user> <sharing> <link-type>

0x0199 end of channel list

	 <channel>

0x019a channel topic

	 <channel> <topic>

	 sent when joining a channel or a new topic is set

404 channel does not exist

0x6d02 message of the day.  sent after client login