::freedb.org::

From a150899221a5badff9740703b754f901b4f52762 Mon Sep 17 00:00:00 2001 From: cinap_lenrek Date: Thu, 14 Apr 2011 17:27:24 +0000 Subject: fill /acme --- acme/bin/source/acd/cddbproto | 894 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 894 insertions(+) create mode 100644 acme/bin/source/acd/cddbproto (limited to 'acme/bin/source/acd/cddbproto') diff --git a/acme/bin/source/acd/cddbproto b/acme/bin/source/acd/cddbproto new file mode 100644 index 000000000..d1a278318 --- /dev/null +++ b/acme/bin/source/acd/cddbproto @@ -0,0 +1,894 @@ + + +::freedb.org:: + + + + + + + + + + +

+ + + +

freedb

.org

a free approach to cddbp +

+ +

+freedb.org - a free approach to cddbp

+ + + + + +
+ + + + + + + + +
+ + + + + + + +
Main Menu
+ + + + + + + +
+ + +
+
Home +
News-Topics +
About +
Developers +
Applications +
Download +
Forum +
Web-based Search +
Web Links +
Your Account +
Submit News + +
+ + +
+
+
+ + +
+ + + + + + + +
FAQ
+ + + + + + + +
+ + +
+ Our FAQ can be found here.
+Please read the FAQ before asking questions via email.
+ + +
+
+
+ + +
+ + + + + + + +
Contact
+ + + + + + + +
+ + +
+ General questions:
+info@freedb.org
+Databaseupdates:
+updates@freedb.org
+(NOT for submission!)
+Please keep in mind that we are NOT the Nero-Support and please do not send CD-submits to the adresses above.
+Submits have to go to:
+freedb-submit@freedb.org
+ + +
+
+
+ + + +
+ + + + + + + +
Downloads
+ + + + + + + +
+ + +
+ The link to the database downloads is here
+ + +
+
+ + + + +
+ + + +
+ CDDB-protocol documentation
+ +

+
+ CDDB Protocol + + By Steve Scherf and Ti Kan + -------------------------- + +Revision: $Id: CDDBPROTO,v 1.6 1997/05/14 07:53:52 steve Exp steve $ + + +Notation: +-> : client to server +<- : server to client + +terminating marker: `.' character in the beginning of a line + + +Server response code (three digit code): + +First digit: +1xx Informative message +2xx Command OK +3xx Command OK so far, continue +4xx Command OK, but cannot be performed for some specified reasons +5xx Command unimplemented, incorrect, or program error + +Second digit: +x0x Ready for further commands +x1x More server-to-client output follows (until terminating marker) +x2x More client-to-server input follows (until terminating marker) +x3x Connection will close + +Third digit: +xx[0-9] Command-specific code + + +CDDB Protocol Level 1: +---------------------- + +Server sign-on banner: +---------------------- +<- code hostname CDDBP server version ready at date + + code: + 200 OK, read/write allowed + 201 OK, read only + 432 No connections allowed: permission denied + 433 No connections allowed: X users allowed, Y currently active + 434 No connections allowed: system load too high + hostname: + Server host name. Example: xyz.fubar.com + version: + Version number of server software. Example: v1.0PL0 + date: + Current date and time. Example: Wed Mar 13 00:41:34 1996 + + +Initial client-server handshake: +-------------------------------- +Note: This handshake must occur before other cddb commands + are accepted by the server. + +Client command: +-> cddb hello username hostname clientname version + + username: + Login name of user. Example: johndoe + hostname: + Host name of client. Example: abc.fubar.com + clientname: + The name of the connecting client. Example: xmcd, cda, EasyCD, + et cetera. Do not use the name of another client which already + exists. + version: + Version number of client software. Example: v1.0PL0 + +Server response: +<- code hello and welcome username@hostname running clientname version + + code: + 200 Handshake successful + 431 Handshake not successful, closing connection + 402 Already shook hands + + +CDDB query: +----------- +Client command: +-> cddb query discid ntrks off1 off2 ... nsecs + + discid: + CD disc ID number. Example: f50a3b13 + ntrks: + Total number of tracks on CD. + off1, off2, ...: + Frame offset of the starting location of each track. + nsecs: + Total playing length of CD in seconds. + +Server response: +<- code categ discid dtitle + or +<- code close matches found +<- categ discid dtitle +<- categ discid dtitle +<- (more matches...) +<- . + + code: + 200 Found exact match + 211 Found inexact matches, list follows (until terminating marker) + 202 No match found + 403 Database entry is corrupt + 409 No handshake + categ: + CD category. Example: rock + discid: + CD disc ID number of the found entry. Example: f50a3b13 + dtitle: + The Disc Artist and Disc Title (The DTITLE line). For example: + Pink Floyd / The Dark Side of the Moon + + +CDDB read: +---------- +Client command: +-> cddb read categ discid + + categ: + CD category. Example: rock + discid: + CD disc ID number. Example: f50a3b13 + +Server response: +<- code categ discid +<- # xmcd 2.0 CD database file +<- # ... +<- (CDDB data...) +<- . + or +<- code categ discid No such CD entry in database + + code: + 210 OK, CDDB database entry follows (until terminating marker) + 401 Specified CDDB entry not found. + 402 Server error. + 403 Database entry is corrupt. + 409 No handshake. + categ: + CD category. Example: rock + discid: + CD disc ID number. Example: f50a3b13 + + +CDDB search: (command not yet implemented in freedb-serversoftware!) +------------ +Client command: +-> cddb srch key search_type ... search_type + + key: + Pseudo-regular expression to match. Expressions should meet the + following description: + + - No white space. + - Printable characters only. + - Case is ignored. + search_type: + CDDB fields to search through. Example: title + Supported types: artist, title, extd, ext, trk + categ: + CD category. Example: rock + +Server response: +<- code matches found +<- categ discid dtitle +<- categ discid dtitle +<- (more matches...) +<- . + + code: + 210 OK, matches found, list follows (until terminating marker) + 401 No match found. + 409 No handshake. + categ: + CD category. Example: rock + dtitle: + The Disc Artist and Disc Title (The DTITLE line). For example: + Pink Floyd / The Dark Side of the Moon + + +CDDB write: +----------- +Client command: +-> cddb write categ discid + + categ: + CD category. Example: rock + discid: + CD disc ID number. Example: f50a3b13 + +Server response: +<- code categ discid + + code: + 320 OK, input CDDB data (until terminating marker) + 401 Permission denied. + 402 Server file system full/file access failed. + 409 No handshake. + 501 Entry rejected: reason for rejection. + categ: + CD category. Example: rock + discid: + CD disc ID number. Example: f50a3b13 + +Client data: +-> # xmcd 2.0 CD database file +-> # ... +-> (CDDB data) +-> . + +Server response: +<- code message + + code: + 200 CDDB entry accepted + 401 CDDB entry rejected: reason why + message: + Message string to indicate write status: + CDDB entry accepted, or CDDB entry rejected. + + +Help information: +----------------- +Client command: +-> help + or +-> help cmd + + cmd: + CDDB command. Example: quit + + or + +-> help cmd subcmd + + cmd: + CDDB command. Example: cddb + subcmd: + CDDB command argument. Example: query + +Server response: +<- code Help information follows +<- (help data ...) +<- . + or +<- code no help information available + + code: + 210 OK, help information follows (until terminating marker) + 401 No help information available + + +Log statistics: +--------------- +Client command: +-> log [[-l lines] [start date [end date]] | [day [days]] | [get"]] + + lines: + The maximum number of lines to print for each data list in the + log statistics. + start date: + The date after which statistics should be calculated. Date is + of the format: hh[mm[ss[MM[DD[[CC]YY]]]]] + + E.g.: 201200053196 for 8:12 PM on May 31, 1996. + 20120005312096 for 8:12 PM on May 31, 2096. + 080530 for today at at 8:15 and 30 seconds. + + If the century ("CC") is omitted, a reasonable guess is made. If + this argument is omitted, all messages are considered. + end date: + The date after which statistics should not be calculated. If + omitted, the end date is assumed to be the current date. + day: + The string "day". This solitary argument will cause a log search + of messages generated within the last day. + days: + A positive numerical argument which modifies the number of days' + messages to searh. If this argument is left out, the default is 1. + get: + The string "get". This solitary argument will cause the server + to send the contents of the log file. + +Server response: +<- code Log summary follows +<- (log stats) +<- . + or +<- code Log follows +<- (log stats) +<- . + + code: + 210 OK, log summary follows (until terminating marker) + 211 OK, log follows (until terminating marker) + 401 Permission denied + 402 No log information available + 501 Invalid start/end date + + +Message of the day: +------------------ +Client command: +-> motd + +Server response: +<- code Last modified: date MOTD follows (until terminating marker) +<- (message text) +<- . + + code: + 210 Last modified: 05/31/96 06:31:14 MOTD follows (until terminating marker) + 401 No message of the day available + date: + The date the text of the message of the day was modified. The date + appears in the following format: + + 05/31/96 06:31:14 + + This value may be used by client software as a message timestamp + for purposes of determining if it has already been displayed. This + format was chosen because it is more easily parsed than the standard + ctime() format. + + +Server protocol level: +---------------------- +Client command: +-> proto [level] + + level: + The (numerical) protocol level to set the server to. + +Server response: +<- code CDDB protocol level: current cur_level, supported supported_level + or +<- code OK, protocol version now: cur_level + + code: + 200 CDDB protocol level: current cur_level, supported supp_level + 201 OK, protocol version now: cur_level + 501 Illegal protocol level. + 502 Protocol level already cur_level. + cur_level: + The current protocol level at which the server is running. + supported_level: + The maximum supported protocol level. + + +Server sites: +-------------- +Client command: +-> sites + +Server response: +<- code OK, site information follows (until terminating `.') +<- (data) +<- . + + code: + 210 Ok, site information follows + 401 No site information available. + + The data format is as follows: + site port latitude longitude description + + The fields are as follows: + site: + The Internet address of the remote site. + port: + The port at which the server resides on that site. + latitude: + The latitude of the server site. The format is as follows: + CDDD.MM + Where "C" is the compass direction (N, S), "DDD" is the + degrees, and "MM" is the minutes. + longitude: + The longitude of the server site. Format is as above, except + the compass direction must be one of (E, W). + description: + A short description of the geographical location of the site. + + Example: + cddb.moonsoft.com 888 N037.23 W122.01 Fremont, CA USA + + +Server status: +-------------- +Client command: +-> stat + +Server response: +<- code OK, status information follows (until terminating `.') +<- (data) +<- . + + code: + 210 Ok, status information follows + + The possible data is as follows: + current proto: <current_level> + An integer representing the server's current operating protocol + level. + max proto: <max_level> + The maximum supported protocol level. + gets: <yes | no> + Whether or not the client is allowed to get log information, + according to the string "yes" or "no". + updates: <yes | no> + Whether or not the client is allowed to initiate a database + update, according to the string "yes" or "no". + posting: <yes | no> + Whether or not the client is allowed to post new entries, + according to the string "yes" or "no". + quotes: <yes | no> + Whether or not quoted arguments are enabled, according to + the string "yes" or "no". + current users: <num_users> + The number of users currently connected to the server. + max users: <num_max_users> + The number of users that can concurrently connect to the server. + strip ext: <yes | no> + Whether or not extended data is stripped by the server before + presented to the user. + Database entries: <num_db_entries> + The total number of entries in the database. + Database entries by category: + This field is followed by a list of catgories and the number + of entries in that category. Each entry is of the following + format: + + <white space>catgory: <num_db_entries> + + The list of entries is terminated by the first line that does + not begin with white space. + + Pending file transmissions: + This field is followed by a list of sites that are fed new + database entries at periodic intervals, and the number of + entries that have yet to be transmitted to that site. + Each entry is of the following format: + + <white space>site: <num_db_entries> + + The list of entries is terminated by the first line that does + not begin with white space. + + This list may grow as needed, so clients must expect possible + unrecognizable data. Also, additional fields may be added to + the currently existing lines, although no existing fields will + be removed or change position. + + +Server version: +--------------- +Client command: +-> ver + +Server response: +<- code servername version copyright + or +<- code Version information follows + + code: + 200 Version information. + 211 OK, version information follows (until terminating marker) + version: + Server version. Example: v1.0PL0 + copyright: + Copyright string. Example: Copyright (c) 1996 Steve Scherf + + +Database update: +---------------- +Client command: +-> update + +Server response: +<- code Updating the database. + or +<- code Permission denied. + or +<- code Unable to update the database. + + code: + 200 Updating the database. + 401 Permission denied. + 402 Unable to update the database. + + +Server users: +------------- +Client command: +-> whom + +Server response: +<- code User list follows + + code: + 210 OK, user list follows (until terminating marker) + 401 No user information available. + + +Client sign-off: +---------------- +Client command: +-> quit + +Server response: +<- code hostname closing connection. Goodbye. + + code: + 230 OK, goodbye. + hostname: + Server host name. Example: xyz.fubar.com + + +General errors: +--------------- + +Server response: +<- code error + code: + 402 Server error. + 408 CGI environment error. + 500 Command syntax error, command unknown, command unimplemented. + 530 Server error, server timeout. + + +Reserved errors: +---------------- + +The following error codes are reserved, and will never be returned as a +response to a CDDB protocol command. They are intended to be used internally +by clients that have a need for generating pseudo-responses. + + 600-699 + + +CDDB Protocol Level 2: +---------------------- + +In all respects, protocol level 2 is the same as level 1, with the exceptions +listed below. + +Arguments to commands may be surrounded by double quotes. All characters +within the quotes, including white space, are included in the argument. All +white space is replaced by the `_' (2Dh) character by the server. White space +is defined as ` ' (20h) and `^I' (control-I, or 09h). + +Arguments containing quotes that should not be interpreted with the special +meaning described above should be escaped with a preceding backslash character, +or '' (5Ch). If an actual backslash appears in an argument, it should be +escaped with a preceding backslash. In both cases, the preceding backslash +will be removed from the input before being interpreted. + + +CDDB Protocol Level 3: +---------------------- + +Protocol level 3 is the same as level 2, with the exception listed below. + +The output of the "sites" command has changed to meet the folowing description: + + The data format is as follows: + site protocol port address latitude longitude description + + The fields are as follows: + site: + The Internet address of the remote site. + protocol: + The transfer protocol used to access the site. + port: + The port at which the server resides on that site. + address: + Any additional addressing information needed to access the + server. For example, for HTTP protocol servers, this would be + the path to the CDDB server CGI script. This field will be + "-" if no additional addressing information is needed. + latitude: + The latitude of the server site. The format is as follows: + CDDD.MM + Where "C" is the compass direction (N, S), "DDD" is the + degrees, and "MM" is the minutes. + longitude: + The longitude of the server site. Format is as above, except + the compass direction must be one of (E, W). + description: + A short description of the geographical location of the site. + + Example: + cddb.moonsoft.com cddbp 888 - N037.23 W122.01 Fremont, CA USA + cddb.moonsoft.com http 80 /~cddb/cddb.cgi N037.23 W122.01 Fremont,CA USA + +Note that a site may appear once for each type of protocol it supports for +accessing the server. + + +Addendum A: Proper use of CDDBP: +-------------------------------- + +There are a few guidelines that must be followed in order to make proper use +of CDDBP: + +- When handshaking with the server via the "cddb hello" command, the client + must specify its own name and version, not that of some other client (such + as xmcd). Also, the "username" and "hostname" must be that of the actual + user running the program, not some hardwired value. + +- Before performing a "cddb read", the client program MUST perform a + "cddb query". Failure to do so may result in the client program receiving + incorrect CDDB data from the server. Also, without performing a query, the + client program will not benefit from close matches in the event of the + lack of an exact match in the database. + +- For accounting purposes, it is best if client programs only perform a single + "cddb query" for a particular disc before performing a "cddb read" for that + disc. + + +Addendum B: CDDBP under HTTP: +----------------------------- + +Accessing a server as a CGI script is done in much the same way as through +direct interaction. The command set is identical, though the method of +communication is through CDDBP commands encapsulated in the HTTP protocol. +The only limitation is that a single command may be executed per connection, +since HTTP is not truly interactive. For the server to be accessed in this +way, it must reside on the target host at a known URL which is accessible by +the host HTTP server. The client program must connect to the HTTP server on +the target host and issue an HTTP command with the appropriate CDDBP command +encapsulated within. + +Commands may be submitted to servers in CGI mode using either the "GET" or +"POST" HTTP commands. Both methods are supported, and there is no real +difference between how both are to be used other than the syntactical +difference between the two methods. The "POST" method may provide the ability +to issue longer commands, though, depending on the architecture of the system +on which the server resides. + +The server command must be sent as part of the "Request-URI" in the case +of the "GET" method, and as the "Entity-Body" in the case of the "POST" +method. In both cases, the command must be of the following form: + +cmd=server+command&hello=joe+my.host.com+clientname+version&proto=1 + +Where the text following the "cmd=" represents the CDDBP command to be +executed, the text following the "hello=" represents the arguments to +the "cddb hello" command that is implied by this operation, and the +text following the "proto=" represents the argument to the "proto" command +that is implied by this operation. + +The "+" characters in the input represent spaces, and will be translated +by the server before performing the request. Special characters may be +represented by the sequence "%XX" where "XX" is a two-digit hex number +corresponding to the ASCII (ISO-8859-1) sequence of that character. The +"&" characters denote separations between the command, hello and proto +arguments. Newlines and carriage returns must not appear anywhere in the +string except at the end. + +All CDDBP commands are supported under HTTP, except for "cddb hello", +"cddb write", "proto" and "quit". + +For example, should user "joe" on system "my.host.com" be running xmcd 2.1, +a read request for his currenly playing CD might look like this: + +cmd=cddb+read+rock+12345678&hello=joe+my.host.com+xmcd+2.1&proto=1 + +The server will perform the implied "proto" and "cddb hello" commands, +and then perform the requested "cddb read" command. + +Server response to the command is encapsulated in the HTTP server response, +and appears in the "Entity-Body" exactly as it would appear using the CDDBP +protocol. Note that the HTTP response "Entity-Header" is not guaranteed to +contain a "Content-Length" field, so clients should be prepared to accept +variable length input. This is no different from operation under CDDBP. The +header will always contain a Mime "Content-Type" field which describes the +body of data as "text/plain". + +For more detailed information on HTTP and Mime, see RFC 1945 and RFC 1521. +
+
+ +

+ +

+
+
+
+
+ + -- cgit v1.2.3