napster messages ================ by drscholl@hotmail.com December 15, 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 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] 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. 2. 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. can be one of the following (converted to big-endian): 0 error message 2 client login message "" 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 Example: foo badpass 6699 "nap v0.8" 3 3 login ack 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. 6 alternate login format this message is used when logging in for the first time after registering (0x07) a nick "" 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 client registration message 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 ""