Nap protocol specification ========================== By cyberalien@users.sourceforge.net 19 March 2002 Original by drscholl@users.sourceforge.net April 7, 2001 0. Foreward by Dr. Scholl 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. 0.1 Foreward by CyberAlien Original document is created by Dr.Scholl. I have fixed some messages, added OpenNap and SlavaNap messages and extentions to messages, added Napigator protocol specification. If you have any comments please mail me at mailto:cyberalien@users.sourceforge.net 1. Recent Changes * Fixed napigator protocol (12 October 2001) * Fixed commands 100, 110 (12 October 2001) * Updated to match opennap 0.44 and slavanap 2.0.0 capabilities (14 Dec 2001) * Fixed description of ban command [612] (19 March 2002) 2. Client-Server protocol Nap protocol uses TCP for client to server communication. Typically the servers run on ports 8888 and 7777. Note that this is different from the `metaserver' (or redirector) which runs on port 8875. Note: Napster 10.3 and older use port 8876 instead of 8875. each message to/from the server is in the form of where and are 2 bytes each. specifies the length in bytes of the portion of the message. Be aware that and 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 }; [The above is for illustrative purposes only, there are much quicker ways to actually encode a number. -ed] The portion of the message is a plain ASCII string. Napster Beta 10.3+ use big-endian format instead of little-endian. This means that 256 would be encoded as { 0x01, 0x00 } and 1 as { 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" Where required, double quotes are used in the description of the messages below. 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 . -ed] Note that unlike the IRC protocol, each line does NOT end in \r\n. The field specifies exactly how much data you should read. 3. Message Types The following section describes the format of the 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 section for each message are given. [SERVER] means that message is sent by server [CLIENT] means that message is send by client [NAPSTER] means that Napster client or server uses this message [OPENNAP] means that this message is supported by OpenNap 0.44 [SLAVANAP] means that this message is supported by SlavaNap 2.0.0 Detecting server type is easy. When user logs in server sends MOTD and OpenNap and SlavaNap sends string "VERSION opennap 0.44" or "VERSION SlavaNap 2.0.0" among other MOTD strings. can be one of the following (converted to big-endian): 0 error message [SERVER] [NAPSTER,OPENNAP,SLAVANAP] Format: 2 login [CLIENT] [NAPSTER,OPENNAP,SLAVANAP] Format: "" [ ] is the port the client is listening on for data transfer. if this value is 0, it means that the client is behind a firewall and can only push files outward. it is expected that requests for downloads be made using the 500 message (see below) is a string containing the client version info 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 build number for the windows client [optional] Example: foo badpass 6699 "nap v0.8" 3 3 login ack [SERVER] [NAPSTER,OPENNAP,SLAVANAP] Format: [] the server sends this message to the client after a succesful login (2). If the nick is registered, the address given at registration time is returned. If the nick is not registered, a dummy value is returned. is added by Napster server. This is probably user's number. 4 version check [CLIENT] [SERVER] [NAPSTER,OPENNAP,SLAVANAP] Format: Server sends [5] if an update is needed and [4] if not. = string, version 2.0b5a sends "2.0" 5 "auto-upgrade" [SERVER] [NAPSTER] Format: Beta5 Format: Napster is out of date, get a new version. Used to be gaping security hole in Beta5. = string, the new version number. = string, hostname of upgrade (http) server = string, filename and are used only by Beta5 Later versions ignore these values. 6 new user login [CLIENT] [NAPSTER,OPENNAP,SLAVANAP] Format: "" This message is used when logging in for the first time to register a new nickname. The client normally checks for an unused nick using the "check nickname" (7) message and upon receipt of a "nickname not registered" (8) from the server will proceceed to log in with this command. note: this message is similar to the 0x02 message, with the addition of on the end Example: foo foo 6699 "nap v0.8" 3 email@here.com 7 nick check [CLIENT] [NAPSTER,OPENNAP,SLAVANAP] Format: Queries the server to see if is already registered. This message is typically used prior to logging in for the first time to check for a valid nickname. Response to this message is one of 8, 9 or 10 8 nickname not registered [SERVER] [NAPSTER,OPENNAP,SLAVANAP] Format: (empty) The server sends this message in response to the "nick check" (7) message to indicate that the specified nickname is not already registered and is ok to use. 9 nickname already registered [SERVER] [NAPSTER,OPENNAP,SLAVANAP] Format: (empty) The server sends this message when the nickname the client has requested has already been registered by another user 10 (0x0a) invalid nickname [SERVER] [NAPSTER,OPENNAP,SLAVANAP] Format: (empty) This server sends this message in response to the "check nickname" (7) messages when the specified nickname is invalid, usually due to bad characters such as spaces or other non-printable characters. The Napster, Inc. servers only accept (upper- and lower-case) nicks comprised of the following: abcdefghijklmnopqrstuvwxyz1234567890_[]{}-@^!$ 11 password check [CLIENT] [NAPSTER,SLAVANAP] Format: This command is used by Napster only during setup sequence. If password is correct server replies with message 12. If not server sends message 0. 12 password OK [SERVER] [NAPSTER,SLAVANAP] Format: (empty) this message is returned in response to message 11 from the client 13 echo??? [SERVER] [NAPSTER] Format: : [args] Prior to issuing a login (2) command, the server will echo back the received numeric and any arguments of any commands it receives. 14 login options [CLIENT] [NAPSTER] NAME:%s ADDRESS:%s CITY:%s STATE:%s PHONE:%s AGE:%s INCOME:%s EDUCATION:%s Example: NAME: kev ADDRESS: CITY: ephrata STATE: pa PHONE: AGE: 60 or older INCOME: $100,000 or more EDUCATION: Graduate Degree No reply is required. 15 Same as 14. Used by Beta7+ (I don't know if previous versions used command 15 or not) [NAPSTER] 100 (0x64) client notification of shared file [CLIENT] [NAPSTER,OPENNAP,SLAVANAP] Format: ""